Gutless Estimating (Mythical Man-Month)
Posted At: Mon 4 Jul 2005	Posted By: Derek Nobuyuki信幸 Wallace
Categories:Software Engineering

From the wisdom of The Mythical Man-Month:

Gutless Estimating

Observe that for the programmer, as for the chef, the urgency of the patron may govern the scheduled completion of the task, but it cannot govern the actual completion. An omelette, promised in two mintues, may be appear to be progressing nicely. But when it has not set in two minutes, the customer has two choices–wait or eatit raw. Software customers have had the same choices.

The cook has another choice; he can turn up the heat. The result is often an omelette nothing can save–burned in one part, raw in another.

Now i do not think software managers have less inherent courage and firmness than chefs, nor than other engineering managers. But false scheduling to match the patron’s desired date is much more common in our discipline than elsewhere in engineering. It is very difficult to make a vigorous, plausible, and job-risking defense of a estimate that is derived by no quantitative method, supported by little data, and certified chiefly by the hunches of managers.

. . .

Until estimating is on a sounder basis, individual managers will need to stiffen their backbones and defend their estimates with the assurance that their poor hunches are better than wish-derived estimates

Despite being written 30 years ago, it’s still so true today… and something we struggle with on a regular basis…
How can we justify in our estimates the time it takes to write good software verus working software?

Scheduling rule of thumb:

• 1/3 Planning
• 1/6 Coding
• 1/4 Component Test and Early System Test
• 1/4 System Testm all components in hand

This and the tar-pit chapter establishing that it takes 9x the effort, time, and resources to produce a quality software systems product… than just a softare program that runs… plus taking 5/6 of the project time in the quote above to be devoted to non-coding tasks….. it’s really difficult to get clients to understand why it all takes so long to do. If we were building a bridge, would they be hurrying us? maybe… but we would never rush through it… that’s how people get killed…. but with software… why do we succumb to the pressures of the client?