Software Estimation

So why are software estimates so difficult? I don’t know, but between technical problems, little details that take forever, customers changing requirements and conflicting requirements, estimates are normally way below the real time that takes to do something (a rule of thumb is just doubling your normal estimate just to be safe).

Steve McConnell just wrote a book (Software Estimation: Demystifying the Black Art), that I recently bought (but still haven’t read –I’m planning to read it soon), that tries to ease this problem and shed some light into the black art. But what can you say, when even someone as knowledgeable as Steve McConnell, misses estimates when building a fort house by 100% (http://blogs.construx.com/blogs/stevemcc/archive/2007/09/23/building-a-fort-lessons-in-software-estimation.aspx). Well, it was just a small construction plan, that most wouldn’t even try to estimate and just plug along.


But there are great lessons to be learned, that apply to software projects:

• Numerous unplanned problems collectively added up
• Underestimation of unfamiliar tasks
• Not decomposing big tasks into smaller subtasks
• Using overly round time units
• Substituting a target for an estimate
• Sweeping numerous little tasks under the estimation rug
• Never creating a real estimate

And some differences to SW projects:

• No way to compromise quality for the sake of schedule
• Schedule overrun was free
• The estimation error didn't really matter, because the project would be done regardless of what the estimate turned out to be

Jeff Atwood analyzes it from a different perspective (http://www.codinghorror.com/blog/archives/000960.html), and concludes that it’s very different (and requires a different skillset and discipline) to build a doghouse or a skyscraper. And the same applies to software (building a toy app is very different from an enterprise application). That is a statement that most programmers would agree but something very hard to explain to a customer (that thinks software is easily changeable without causing structural problems or bugs).

More recently (http://www.codinghorror.com/blog/archives/000981.html) Jeff took another look at estimation and current practices (planning poker sounds great) and reviews the FogBugz tool from Joel Spolsky (from the Joel on Software fame). Apparently the tool has evolved from a bug tracker to a project management tool.

The tool uses a method called evidence based scheduling (a Monte Carlo simulation based on the historical estimates of developers), that predicts when will software ship (not an exact date, but the probability that software will ship on said date).

You can also see the estimation probabilities for the developers:


So how do you know if the tool is any good? Well, I haven’t tried it, but coming from Joel Spolsky's company, it has a good chance of being high quality (attention to detail, good UI). But you can see a video from the new version of the tool FogBuz 6.0 Movie Demo, try it out or read abook about it by Mike Gunderloy: Painless Project Management with FogBugz.