latest / Estimates are lies, and that's fine
The dirty secret of software estimation is that everyone knows the number is wrong before it leaves your mouth. The PM knows. You know. The PM knows you know. You’re both performing a small ritual whose actual purpose is something other than predicting the future.
What the ritual is for is usually one of:
- Sanity check. Is this two days or two months? You can answer that. The answer is useful. The fact that two days might be five days is noise at this resolution.
- Scope negotiation. “If it’s a week we do it; if it’s a month we don’t.” The estimate is a price tag, not a forecast.
- Forcing a design conversation. You can’t estimate what you haven’t thought about, and an estimate is a cheap way to discover that nobody has.
The trouble starts when people use an estimate produced for purpose (1) as input to a Gantt chart for purpose (4: predicting a delivery date), and then treat the variance as a personal failure of the engineer.
The honest version of estimation is: give a t-shirt size, name the things that would make it bigger, and revisit when you know more. If someone insists on a date, give them a range, and make the range honest — the upper bound should be a number that genuinely feels too high. It isn’t. It never is.
I have lost this argument approximately a hundred times. I keep having it because the alternative is treating engineers like sandwich artists with a stopwatch, and the sandwiches keep arriving late and slightly wrong.