Why Your Estimates Are Always Wrong

Why Your Estimates Are Always Wrong

"How long will this take?"

I have answered that question wrong more times than I can count. Confidently wrong. "Two days" that became two weeks. "Quick fix" that ate a month. And for years I assumed it was a personal failing — that better engineers estimated better.

They don't. Estimates are wrong for structural reasons, and understanding those reasons is the only thing that ever helped me. Here's why your estimates are always wrong, and what actually moves the needle.

Quick Answer

Your estimates are wrong because software estimation is predicting the duration of work you haven't fully understood yet — and you can't accurately predict what you haven't discovered. Padding doesn't fix it. What helps is estimating ranges instead of points, breaking work down until the unknowns surface, tracking your own historical accuracy, and treating an estimate as a forecast that updates, not a promise carved in stone.

The estimate is a prediction about the unknown

Here's the root of it. When someone asks "how long will this take?", they're really asking you to predict the duration of a journey through territory you haven't mapped yet.

If the work were fully understood — every edge case, every integration, every surprise — it would already be half done. The reason it needs doing is that parts of it are still unknown. And you cannot accurately estimate the unknown. By definition.

So every estimate is really a guess about how many surprises are hiding in the parts you haven't looked at closely. The "two days that became two weeks" wasn't bad math. It was the third-party API that behaved nothing like its docs, the edge case nobody mentioned, the refactor the task secretly required. None of those were visible when I gave the estimate.

An estimate isn't a measurement of the work. It's a guess about how many unknowns are hiding in it.

This reframe matters because it stops you blaming yourself and starts you attacking the real problem: reducing the unknowns before you commit to a number. Learning to talk honestly about uncertainty instead of performing false confidence is one of the quieter parts of the brutal truth about becoming a senior developer.

Photo by Lucas Andrade on Pexels

The planning fallacy is wired into your brain

Even setting aside unknowns, your brain is rigged to underestimate. It's called the planning fallacy, and it's one of the most robust findings in all of behavioral science: people systematically underestimate how long their own tasks take, even when they know they've underestimated before.

Why? Because when you imagine a task, you imagine the happy path. The version where everything goes right. You don't imagine the meeting that derails Tuesday, the dependency that breaks, the "while I'm in here I should also fix…" rabbit hole. The American Psychological Association has documented the planning fallacy for decades — it's a stable cognitive bias, not a personal weakness you can willpower away.

You estimate the best case and then reality serves you the average case, which always includes some friction.

The cruelest part: experience doesn't cure it. Senior engineers underestimate too — they've just learned to multiply their gut number by some painful personal constant. Which is itself a kind of admission that the gut number is structurally too low.

Decomposition is the only real fix

If unknowns are the enemy, the cure is to convert unknowns into knowns before you estimate. And the tool for that is breaking the work down until it stops being scary.

Here's the pattern I trust now. A vague task is a black box full of surprises. Break it into pieces, and three things happen:

1. The pieces you understand get easy to estimate.
2. The pieces you don't understand stick out — and those are exactly where the risk lives.
3. The act of breaking it down forces you to actually think through the work, which surfaces unknowns while they're still cheap.

A task you can't break down is a task you don't understand well enough to estimate. The inability to decompose is the warning sign — the same signal I leaned on heavily in the engineering habit that doubled my output.

// "build the import feature" -> 3 days??  (a guess about a black box)
// break it down:
//   - parse the CSV            -> 0.5d  (known)
//   - validate rows            -> 1d    (known)
//   - map to our schema        -> ??    (UNKNOWN - their format is weird)
//   - handle partial failures  -> ??    (UNKNOWN - what's the UX?)
//   - dedupe against existing  -> 1d    (known)
// the two ?? lines are the whole risk. now we know where to look first.

Suddenly the estimate isn't a single brave guess. It's a sum of small known pieces plus two clearly-flagged unknowns I should go investigate before promising anything.

Estimate ranges, not points

This one change improved my estimates more than anything else: I stopped giving single numbers.

"Two days" is a lie of false precision. It hides all the uncertainty in a confident-sounding point. The honest answer is almost always a range, and the width of the range communicates the thing that actually matters — how much you don't know.

A wide range isn't you being wishy-washy. It's you being honest about risk, which lets the people planning around you make better decisions than a confident wrong number ever could. A two-to-ten-day range is a flag that says "this needs investigation before anyone commits to a date" — and that flag is worth more than a comfortable lie.

Photo by Daniil Komov on Pexels

Track your own history, because your gut lies

The last piece is humbling and effective: measure how wrong you actually are.

Most engineers never compare their estimates to reality. So they never calibrate, and they repeat the same optimism forever. I started keeping a dead-simple log: what I estimated, what it actually took.

The pattern that emerged was brutal and useful. My tasks took, on average, around twice my first instinct — and the more confident I felt, the worse the ratio, because confidence meant I'd skipped the decomposition. Now I have a personal correction factor based on real data, not vibes.

A few practical habits that fall out of this:

• Log estimate vs actual for a month. You'll find your personal multiplier. Apply it ruthlessly.
• Estimate effort, then convert to calendar time separately. "Two days of work" is not "done in two days" — meetings, reviews, and context-switching stretch it. Keep those two numbers distinct.
• Re-estimate as you learn. An estimate from before you started is the least informed one you'll ever have. Update it the moment the unknowns reveal themselves, and tell people early when it moves.
• Use tooling to remove guesswork. Anything that shrinks the work — good developer tools, automation, AI assistants for boilerplate — both shortens the task and reduces the unknowns that wreck estimates.

The bottom line

Your estimates aren't wrong because you're careless or bad at math. They're wrong because you're being asked to predict a journey through unmapped territory, with a brain wired for optimism, under pressure to sound confident.

An estimate is a forecast, not a promise. The honest unit of estimation isn't a number — it's a range whose width tells the truth about what you don't yet know.

The fix isn't to estimate harder. It's to break the work down until the unknowns show themselves, speak in ranges, update as you learn, and track how wrong you've been before. Do that and you won't become a perfect estimator — but you'll become a trustworthy one, which is far more valuable.

If this reframes even one estimate from a brave guess into an honest range, try it on your next "how long?" — and the senior-developer pillar gathers more of these career-shaping shifts.

So next time someone asks "how long will this take?" — what would it look like to answer with an honest range and a plan to shrink it?

Key Takeaways

• Estimates fail because you're predicting work you haven't fully understood—unknowns are the real enemy, not poor math. Break tasks down until the unknowns surface before committing to numbers.
• Your brain is wired to underestimate (planning fallacy): you imagine the happy path, not the average case with friction. Experience doesn’t cure this—calibrate with historical data instead.
• Replace single-point estimates with ranges (e.g., '2–5 days'). The width of the range signals uncertainty, helping stakeholders plan better than a confidently wrong number.
• Decompose vague tasks into smaller pieces to expose hidden risks. If you can’t break it down, you don’t understand it well enough to estimate—flag it for investigation first.
• Track your estimate vs. actual time for a month to find your personal bias (e.g., 'my gut is 2x too optimistic'). Apply this multiplier ruthlessly to future estimates.
• Update estimates as you learn—an initial guess is the least informed. Communicate changes early to avoid surprises, and separate 'effort time' from 'calendar time' (meetings, reviews, etc.).