Software Estimation - Never Underestimate

11th July 2016By Estimation

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

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' from clients, professional pride and management.

The author argues 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% of the time (and on a budget). Their data has also shown that overrun were about 120% (time) and 100% in costs. Capers Jones (1998) data shows the larger project (LOC) the less 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.