Software Estimation - Never Underestimate (Part 1)

I had a chance to get my hands on the Software Estimation - Demystifying the Black Art by Steve McConnell. I must admit it is fantastic and well-written book, so I thought I share some of the key things I've learnt. This article is the 1st part of a series of relatively short articles summing up.

Software estimation is an objective measure and an unbiased analytical process for predicting the time and costs of a software process. It is not the same as planning which tends to be a more biased and goal-seeking process. Estimations therefore are unlikely to be a single number and indeed they are often represented by a probability. The (unrealistic) graph below shows month vs probability of completion:

Sample probability distribution for a project 'completion'

It is important to make sure that the range of predictions not 'too wide' not 'too narrow'. This is problematic primarily due to pressure such as client, professional pride and management.

The author argue that it is better to overestimate than it is to underestimate. The price for overestimation is bounded and linear whilst for underestimation it is unbounded and almost exponential (or at least non-linear). The overestimation is usually linked with the so called Parkinson's Law whereby the work expands so as to fill the time available for its completion. However, the consequences of underestimation are far more severe.

  1. Statistically less likely to complete project on time
  2. Poor technical foundations such as planning, collecting requirements and choosing architecture
  3. Destructive late-project dynamics such as more frequent meetings with clients and management, more discussions

The Standish Group published a survey (1994-2004) project were delivered: 54% late, 18% failed and 28% on time (and on budget). Their data has also shown that overrun was about 120% (time) and 100% in costs. Capers Jones (1998) data shows the larger project (LOC) theless chance of being completed on time or failing outright.

The most important conclusion we can gain from all of these data follow:

The software does not have a neutral estimation problem. The industry data shows clearly that the software industry has an underestimation problem.

Leave Comment

Your email address will not be published.

Please type the characters of this captcha image in the input box

Please type the characters of this captcha image in the input box