Why the delay is the whole technique
Nothing about an on-the-spot estimate is better than a considered one, and the difference is not accuracy alone. A number given immediately arrives without the assumptions it depended on, so it travels onwards as a bare figure. Slowing down is what lets the estimate carry the conditions under which it holds — which is the part that protects you when the requirements turn out to be different from what was described in the corridor.
The line for when they insist
One answer contributed the most quotable response in the thread, for meetings where the request is a ballpark and the description is vague: if you want an answer today, it is a year and a million; if you would like to give me the details and some time to review them, the numbers can be refined. They reported that this almost always makes the point. It works because it is not a refusal — it prices the immediacy rather than declining the question.
When you cannot get better requirements
- Estimate against the requirements you actually have and fill the gaps with stated assumptions, so the number is attached to a specific reading of the request.
- Say which assumptions those are, so a wrong one is visibly the reason the estimate moved rather than an unexplained overrun.
- One answer called estimation the single hardest task in the discipline, with eliciting requirements close behind — the two problems being the same problem.
The freelancer's version
- One contributor billed for the time spent estimating, and reported it running to a fifth or a quarter of what they billed overall.
- That paid for real analysis: going into the code, identifying what would change and what it would affect, rather than guessing.
- The client in that arrangement had specifically wanted accurate estimates, and this is what accuracy costs.
- It also aligns the incentives — an estimate nobody pays for is an estimate nobody has time to do properly.