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