Estimating Software Projects

Estimating how long it will take to finish a software project is one of the toughest parts of software engineering. Luckily it's easier to get better: start making estimates now and track your accuracy.

Two rules of thumb:

1. Make a guess and double it. I find this one surprisingly accurate. Probably because I tend to work on the same sorts of projects; but then don't most programmers!
   
2. Brook's book The Mythical Man Month says that every app has a core set of functionality that can be done in X weeks. To create a product will take 9X because of all the wrapper code for config/reporting/error handling, and all the user documentation that needs to be provided. People constantly underestimate this factor of 9.

We normally provide estimates that include design, coding, user docs, but not QA. My manager likes an estimate to broken down into a list of tasks that fit on a single page. Tasks that you are most unsure of should be clearly identified by using a range such as "4-10 weeks".

The whole game of making & meeting estimates is about what features are "in" and what's "out". I like to tie estimates to an explicit list of what features users will and won't get. Requirements are bound to change, and managers sometimes have a habit of forgetting that your estimate was tied to a feature set.

As usual, Joel has written on this already.