Falsehoods Programmers Believe About Projects

Years ago, Patrick McKenzie, wrote an article titled Falsehoods Programmers Believe About Names.  The article inspired a short lived burst of other programming falsehoods.  This is a very late entry in the genre, covering incorrect assumptions about software projects.

All of these assumptions are wrong.  Try to make fewer of these assumptions when working on projects.  Since you are always working on projects at work, always be questioning your assumptions about projects.

1. Projects have defined beginnings.
2. Maybe not formal beginnings, but there is a point when you are supposed to start work.
3. Your manager knows when you should start working.
4. You can use your priorities to determine when you should start working.
5. You should be working on the project because you were asked.
6. You should not be working on the project because you weren’t asked.
7. Projects have defined endings.
8. Successful projects have endings.
9. Failed projects have endings.
10. The project will solve the problem.
11. The project will solve a problem.
12. The project won’t make the problem worse.
13. Everyone on the project agrees on what problems the project is supposed to solve.
14. Everyone agrees about what solving the problems means.
15. Solving the problem will make the project a success.
16. Not solving the problem will make the project a failure. 
17. There is a relationship between the project’s success and the status of the problem.
18. The software you are asked to write will solve the problem.
19. The software you are asked to write will make the project a success.
20. Writing the software you are asked to write means you are doing a good job.

At best, projects are best guesses by well intended people.  At their worst, projects can become meaningless busywork that is completely unrelated to any problems or desires at a company.  The fewer false assumptions you buy into the more effective you will be.