I want to take a little time to write about why software development estimates are notoriously incorrect.  The reason is very simple.  No one can come close to knowing how long it will take to finish a software product at the beginning of the project.   If someone says they can, they probably are trying to get your money.  We really can’t do it and I have proof.

It is either greatly misunderstood or ignored that studies have been done about this and been re-hashed over and over in numerous books and methodologies.  The evidence is probably best descriped by the “Cone of Uncertainty”.   The cone expresses the best the industry is capable to date, and it appears to be getting worse.  Here it is:

This tells us that the best estimates that can be provided at the outset of a project only provide accuracy of 4x to .25x.  This means that if the estimate is 1 year, it could end up taking from 3 months to 4 years.  That is the best it gets folks.

In my experience I have found, but not scientifically proven, that the cost of determining an accurate estimate in advance is higher than the cost of developing the software itself.  What think I am observing is that the cheapest way to determine how long the software will take to make, is to make the software and find out. If you think about it, this makes sense.

An observation about the cone of uncertainty is that as time goes by, the range of estimation error decreases if an effort is made to reduce variability during the project.  The problem is that estimates have a cost in both time and effort and the predictability may not be worth it.  That’s something that that those involved in software product ventures need to consider.

Invention and discovery have never been easy to estimate.  If you doubt this study Edison and Christopher Columbus and those who funded them.  The important thing wasn’t that Christopher Columbus got to India, but that he produced value.  That is something we need to consider when embarking on an effort that primarily involves invention and discovery.  Am I saying not to plan?  No.  Am I saying take the plan with an enormous grain of salt? Yes.  Do I think that there is a way to do estimates that help? Yes, and I hope to talk about that more in the days to come.