Why Estimates Are Always Wrong
Software estimation fails for a fundamental reason: we estimate based on the parts of the work we can see, but the parts that blow our timelines are the ones we can't see. The unknown unknowns.
This isn't incompetence. It's structural. You can't estimate what you don't know exists. A 2-day task becomes 2 weeks because you discovered the third-party API doesn't support what you needed, the database schema needs migrating, and the existing code in that area is more complex than expected. None of these were visible when you estimated.
What People Actually Want From Estimates
When a PM or stakeholder asks "how long will this take?", they're rarely asking for a precise number. They're asking one of these questions:
- Is this feasible at all?
- Can it be done before the deadline I'm thinking of?
- Should we plan other work around this, or assume it'll be done quickly?
An estimate that answers the real question is more valuable than a precise number that answers the literal question.
Better Ways to Estimate
Give ranges, not points. "3 to 7 days" is more honest than "5 days" and conveys the uncertainty that exists. Most engineers feel social pressure to give a single number. Resist it.
Separate known from unknown. "The part I understand well is about 2 days. There's one area I'm not sure about — that could add 0 to 3 days depending on what I find." This is more useful than a single number.
Estimate in phases. "I'll spend a day investigating and then give you a better estimate." This front-loads the discovery work before committing to a timeline.
Track your estimates. The engineers who estimate best aren't more psychic than the ones who estimate worst. They've recorded their estimates and their actuals long enough to know their personal bias. Most people are 2-3x optimistic. Knowing that, you adjust.
The One Rule
If you give an estimate and you discover you're going to miss it, say so immediately. Not at the deadline — when you discover it.
An estimate revised upwards early is manageable. The same revision at the deadline is a crisis.
Surprises are almost always worse than bad news delivered early.