'Two days' regularly becomes a week and a half — not because engineers are bad at math, but because an estimate is really a guess about how much you don't yet know you don't know.
2 min read
When a two-day estimate turns into a week and a half, the actual coding often really did take close to two days. The rest of the time went to things the estimate never accounted for: a dependency that turned out to be undocumented, an edge case discovered halfway through, a "quick" code review round that took three days because the reviewer was on vacation, or a staging environment that broke for unrelated reasons. Estimation isn't bad at predicting known work — it's structurally bad at predicting the unknown work an unfamiliar problem always contains a little of.
More careful estimation helps, but it can't fully close this gap, because the very thing that makes a task hard to estimate — how much of it is genuinely unfamiliar — is also what makes it hard to see how much is unfamiliar before starting. This isn't a personal failing; it shows up on every team, senior engineers included, which is why the practical fixes below work at the process level instead of just asking people to guess harder.
An estimate is a communication tool, not a promise carved in stone — its real job is giving whoever's planning around it an honest sense of uncertainty, not a number that sounds confident. Padding every estimate without saying so, or presenting a guess as a guarantee, causes more damage long-term than an honestly-stated range that turns out to need updating once the unfamiliar parts of the work become clear.
Check your understanding
A quick comprehension check — not tracked, not graded, just for you.
1. When a 2-day estimate turns into a week and a half, what does this lesson say usually happened?
2. Why does breaking work into smaller pieces before estimating help?
3. Why does giving a range instead of a single number help communicate an estimate honestly?
Software Engineering Fundamentals