Chapter10.Estimating

Chapter 10. Estimating

One of the mysteries of software development is why even the best programmers are so bad at estimating the time it will take them to get done. Either their estimates are wildly optimistic or, at the other extreme, overly conservative. When you get an estimate of "a couple of weeks" for some major subsystem to be created from scratch and, the same morning, the same estimate for what you think should be a two-line fix, you know that something ain't right. It's even worse if the two estimates come from the same programmer, although that would be a pretty rare occurrence!

I have to admit that I have not discovered any great secrets to good estimating. What I have discovered is that younger, more inexperienced developers tend to be too optimistic. A good antidote is to review their estimates with more senior people, including the architect for the project. In some cases, the developer may be thinking of a particularly "clever" implementation that will get the job done very quickly. On the other hand, if his approach is at odds with the overall architecture of the project, it will all be for naught. So, very aggressive estimates need to be put under the microscope and thoroughly discussed. The usual outcome is a better understanding of the problems and a better, albeit longer, estimate.

What about the other fellow? The overly conservative estimates come from doing a detailed "bottoms up" study of the problem, and they suffer from including safety factors at every step. All these safety factors accumulate; it is almost as though you are planning for everything to go wrong at every step, which rarely happens, Murphy notwithstanding. These estimates also suffer from the compartmentalization effect. Good developers work on problems in bunches, especially if they are fixing bugs. Often, for example, several problems can be isolated to one part of the code that needs overhaul; by getting into that section and cleaning it up, developers can address several problems in one pass. If you did an estimate on a bug-by-bug basis, you would likely wind up with something at least two to three times as long as the job will really take.

It turns out that some developers do "sandbag." That is, they purposely give long estimates, either because they have been burned in the past, or because they really don't want to work on that particular problem. The good manager needs to be very patient and work on establishing an environment of trust surrounding estimates. No one should be severely punished for honestly missing an honest estimate. On the other hand, irresponsible estimatinggiving a number without sufficient thoughtand sandbagging should be actively discouraged.