The art of software estimation »
FERDY CHRISTANT - APR 1, 2008 (04:38:16 PM)
Yesterday and today I was in a company internal course about software estimation. Estimation in this case meaning the estimation of software size, development cost, time, and other critical resources (people, hardware, etc). Looking back at the last two days I will have to admit that this was a largely blank spot in my skill set.
Up until know I was only really familiar and experienced with the so-called expert estimations. In other words: let the developer make an educated guess. The more experienced the developer, the better the estimates. The accuracy of the expert estimate will improve if you ask more developers and calculate the average. Appearantly this is called Wide Delphi.
It turns out there are various other techniques, such as CoCoMo, FPA, Pair-wise comparisons, Fuzzy Logic, Software Equation, and much more. Most of these methods are statistical ways to estimate based upon historical data. I was surprised to find so much math in these models. Where I though estimation was a grey, gut-feeling kind of process, it turns out that professional software estimation is in fact more black-and-white, dry calculations and hard numbers.
There were also plenty of eye-openers, just to name a few:
- The difference in productivity between beginners and experts in a domain can be up to 30. Needless to say, the term "expert", "senior" and such are highly subjective terms in the IT domain.
- No matter how many extra people you put on a project, a project's estimated delivery date cannot be compressed by more than 30%.
- Reuse of code is not free. In fact, reusing a line of code costs as much as writing 0.3 new lines of code. Removing code is not free either.
- There are 18 cost drivers that are typically not taken into account in the average project, for example team cohesion and platform familiarity. In the very worst case, when all these 18 parameters are at their lowest, they together have an influence of 10000% (a 100 times the estimated project cost)
- The perfect estimate is the point where there is a 50% chance that the actuals will be less, and a 50% chance that the actuals will be more.
- You should never give out a hard estimate. Instead, give out a range, along with the probability that you will meet the minimum, expected and maximum cost.
I would recommend any developer or architect to follow a similar course. It is in fact good fun, and nowadays it takes more than just writing good code to be a good developer. Whilst on the subject of learning, you may be interested in my earlier article: Learning strategies for developers.