101 Ways To Know Your Software Project Is Doomed

101 Ways To Know Your Software Project Is Doomed

1. Management has renamed its Waterfall process to Agile Waterfall 

2. You start hiring consultants so they can take the blame 

3. The Continuous Integration server has returned the error message "Fuck it, I give up" 

4. You have implemented your own Ruby framework that uses XML configuration files 

5. Your eldest team member references Martin Fowler as a 'snot-nosed punk' 

6. Your source code control system is a series of folders on a shared drive 

7. Allocated QA time is for Q and A why your crap is broken 

8. All of your requirements are written on a used cocktail napkin 

9. You start considering a new job so you don't have to maintain the application you are building 

10. The lead web developer thinks the X in XHTML means 'extreme' 

11. Ever iteration meeting starts with "Do you want the good news or the bad news..." 

12. Your team still gives a crap about its CMM Level 

13. Progress is now measured by the number of fixed bugs and not completed features 

14. Continuous Integration is getting new employees to read the employee handbook 

15. You are friends with the janitor 

16. The SCRUM master doesn't really care what you did yesterday or what you will do today 

17. Every milestone ends in a dead sprint 

18. Your best developer only has his A+ Certification 

19. You do not understand the acronyms DRY, YAGNI, or KISS; but you do understand WTF, PHB, and FUBAR 

20. Your manager could be replaced by an email redirection batch file 

21. The only certification your software process has is ISO 9001/2000 

22. Your manager thinks 'Metrics' is a type of protein drink 

23. Every bug is prioritized as Critical 

24. Every feature is prioritized as Trivial 

25. Project estimates magically match the budget 

26. Developers use the excuse of 'self documenting code' for no comments 

27. Your favorite software pattern is God Object 

28. You still believe compiling is a form of testing 

29. Developers still use Notepad as an IDE 

30. Your manager wastes 7 hours a week asking for progress reports (true story) 

31. You do not have your own machine and you are not doing pair programming 

32. Team Rule - No meetings until 10 AM since we were all here until 2 AM 

33. Your team believes ORM is a 'fad' 

34. Your team believes the transition from VB6 to VB.NET will be 'seamless' 

35. Your manager thinks MS Project is the best management tool the market offers 

36. Your spouse only gets to see you on a webcam 

37. None of your unit tests have asserts in them 

38. FrontPage is your web page editor of choice 

39. You get into flame wars if { should be on new line, but you are impartial to patterns such as MVC 

40. The company motto is 'Do more with less' 

41. The phrase 'It works on my machine' is heard more than once a day 

42. The last conference your .NET team attended was Apple WWDC 2000 

43. Your manager insists that you track all activity but never uses the information to make decisions 

44. All debugging occurs on the live server 

45. Your manager does not know how to check email 

46. Your manager thinks being SOX compliant means not working on baseball nights 

47. The company hires Senetor Ted Stevens to give your project kick-off inspiration speech 

48. The last book you read - Visual InterDev 6 Bible 

49. The overall budget is mistaken for your weekly Mountain Dew bill 

50. Your manager spends his lunch hour crying in his car (another true story) 

51. Your lead web developer defines AJAX as a cleaning product 

52. Your boss expects you to spend the next 2 days creating a purchase request for a $50 component 

53. The sales team decreased your estimates because they believe you can work faster 

54. Requirement - Rank #1 on Google 

55. Everyday you work until Midnight, everyday your boss leaves at 4:30 

56. Your manager loves to say "Why do the developers care? They get paid by the hour." 

57. The night shift at Starbucks knows you by name 

58. Management can not understand why anyone needs more than a single monitor 

59. Your development team only uses source control as a power failure backup system 

60. Developers are not responsible for any testing 

61. The team does not use SVN because they believe the merge algorithms are black voodoo magic 

62. Your white boards are mostly white (VersionOne) 

63. The client continually mistakes your burn-down chart for a burn-up chart