Software Craftsmanship & Practice
Estimating
An estimate is a probabilistic statement about the future, not a promise — communicated honestly as a range with explicit assumptions, and calibrated over time against how your own past estimates actually turned out.
- State an estimate as a range (best-case / most-likely / worst-case) rather than a single number that inevitably gets treated as a deadline
- Break a large, uncertain task into smaller pieces — each piece can be estimated with tighter confidence than the whole
- Track estimate-vs-actual over time; most people are systematically optimistic, and only measurement reveals your own personal bias
- "It depends" is a legitimate, useful answer — followed immediately by what it depends on
- The tighter the estimate demanded, the more it costs to produce — a rough order-of-magnitude answer is cheap; a precise one requires doing much of the design work first
| Task size | Credible range | Why |
|---|---|---|
| A few hours | ±20–30% | Small enough to reason about directly |
| A few days | ±50% or wider | Unknowns start compounding |
| Weeks, unbroken down | Barely more than a guess | Too many hidden sub-tasks to have accounted for them all |
The instinct to demand (or give) a single number — "how long will this take?" / "three weeks" — discards the uncertainty that was actually there and replaces it with false precision. A range communicates the same information honestly: "most likely three weeks, could slip to five if the migration turns out to be harder than expected, could be two if it goes smoothly." Whoever receives that estimate can plan around the uncertainty instead of being blindsided when reality lands anywhere other than exactly the single number given.