Why Your Estimates Are Always Wrong

Someone asks: "How long will this take?" You think about the feature. You consider the components. You mentally walk through the implementation. You arrive at a number. "About two weeks."

It takes five weeks. It always takes five weeks when you say two. You're not bad at estimating. You're human, and humans are systematically bad at estimating software work for reasons that have nothing to do with skill or experience.

Understanding why estimates fail is more useful than trying to make perfect estimates. Perfect estimates aren't achievable. Less-wrong estimates are.

Why Software Is Uniquely Hard to Estimate

Unknown Unknowns

When you estimate a feature, you're estimating based on what you know the work involves. But software work consistently includes things you didn't know about until you started:

• The API you planned to use doesn't support the operation you need

• A dependency has a bug that requires a workaround

• The database schema needs a migration you didn't anticipate

• The design that seemed straightforward in planning is awkward in practice

• A requirement you assumed was simple has edge cases that triple the scope

These aren't failures of planning. They're inherent to the work. Software development is exploration — you're often building something that doesn't exist yet, in a system whose full behavior you can't predict until you interact with it.

Physical construction has blueprints, material specifications, and well-understood processes. A contractor estimating a kitchen renovation is working with known materials in known configurations. Software has none of that. Every feature is a novel composition of components that may or may not work together the way you expect.

The Planning Fallacy

Daniel Kahneman's planning fallacy: people consistently underestimate the time required to complete tasks, even when they know they've underestimated in the past.

The mechanism: when you estimate, you imagine the best-case scenario — everything goes according to plan, no interruptions, no blockers, no surprises. Your estimate reflects this imagined path. The actual path includes meetings, context switches, code review cycles, debugging, and the unknown unknowns described above.

Experienced developers aren't immune to this. They've been burned by bad estimates before, but the next estimate is still optimistic — because the planning fallacy is a cognitive bias, not a knowledge gap. Knowing about it helps, but doesn't eliminate it.

Scope Is Not Fixed

The requirement you're estimating today is not the requirement you'll deliver. Requirements evolve as stakeholders see progress, as edge cases emerge, and as the team learns more about the problem. "Add a search feature" on Monday becomes "add a search feature with filters, saved searches, and autocomplete" by Friday.

This isn't scope creep from bad management — it's the natural process of understanding a problem better as you solve it. But it means your estimate was based on a different problem than the one you ended up solving.

Techniques for Being Less Wrong

Break It Down

Large estimates are more wrong than small estimates. "How long to build the search feature?" is a one-month estimate with 3x variance. "How long to add a text input that calls the search API and displays results?" is a two-day estimate with 1.5x variance.

Decompose the work into tasks that are 1-3 days each. Estimate each task individually. Sum the estimates. The errors in small estimates tend to partially cancel out (some take longer, some take less), producing a total that's more accurate than a single big estimate.

If you can't decompose a task into 1-3 day pieces, you don't understand the work well enough to estimate it. That's a signal to do a spike (a time-boxed exploration) before estimating.

Multiply by Pi

This isn't entirely a joke. Developers commonly underestimate by a factor of 2-3x. If your gut says two weeks, the answer is probably closer to five or six weeks.

The "multiply by three" heuristic is crude but effective as a sanity check. If your estimate sounds right to you, it's probably too optimistic. If your estimate sounds uncomfortable — "that seems like a lot" — it's probably in the right range.

Use Ranges, Not Points

"This will take two weeks" is a point estimate with hidden confidence. "This will take 1-3 weeks" is a range that explicitly communicates uncertainty.

Better yet: "I'm 80% confident this takes 1-3 weeks, and 95% confident it's under 5 weeks." The wide range isn't a sign of ignorance — it's honest acknowledgment that software work has inherent variance.

Stakeholders initially dislike ranges because they want a single number to plan against. But a single number that's consistently wrong is less useful than a range that's consistently accurate. Over time, ranges build more trust than optimistic point estimates that are always missed.

Track Your History

Keep a record of estimates vs. actuals. After a few months, you'll see your personal bias: do you consistently underestimate by 2x? By 3x? The data gives you a personal correction factor.

Feature A: Estimated 3 days, Actual 8 days (2.7x)
Feature B: Estimated 5 days, Actual 12 days (2.4x)
Feature C: Estimated 2 days, Actual 3 days (1.5x)
Average ratio: 2.2x

If your average ratio is 2.2x, multiply your gut estimates by 2.2. This is crude but more accurate than your uncorrected instincts.

Reference Class Forecasting

Instead of estimating from first principles ("this feature involves X, Y, and Z"), estimate by comparison to similar past work. "The last three features of this complexity took 8, 12, and 10 days. So probably 8-12 days."

This approach bypasses the planning fallacy by using real data instead of imagined plans. You're not predicting what will happen — you're observing what has happened in similar situations.

The Spike

When you genuinely don't know how long something will take — new technology, unfamiliar domain, unclear requirements — estimate the estimate. "Give me two days to explore the approach, and then I can estimate the full feature."

Two days of exploration converts unknown unknowns into known unknowns, which dramatically improves estimate quality. The spike costs two days. The bad estimate it prevents costs weeks of misaligned expectations.

Communicating Estimates

Never Give a Single Number Under Pressure

"How long?" asked in a meeting, without preparation, produces the worst estimates. Your brain generates the optimistic path and you say it aloud. Now it's a commitment.

"I need to look at the work before I can give you a good estimate. I'll have one by tomorrow." This is professional. It's honest. It produces better estimates.

Explain What's Not Included

"Two weeks to build the feature. That doesn't include code review time, QA, deployment, or documentation. With those, it's closer to three weeks."

Every estimate makes assumptions about scope. Making those assumptions explicit prevents the conversation where the feature is "done" in two weeks but takes another week to ship.

Update When You Learn More

Your estimate at the start of the project is the worst estimate you'll give — because you have the least information. As you build, you learn things that change the estimate. Communicate those changes early.

"I estimated two weeks. After two days of work, I've discovered the API integration is more complex than expected. Updated estimate: three weeks."

Early updates build trust. Late surprises destroy it. An updated estimate at day two is a course correction. An updated estimate at day twelve is a missed deadline.

Key Takeaway

Software estimates are systematically wrong because of unknown unknowns, the planning fallacy, and evolving scope. Be less wrong by decomposing into small tasks, using ranges instead of points, tracking your historical accuracy, using reference class forecasting, and running spikes when uncertainty is high. Communicate estimates with explicit assumptions, avoid snap estimates under pressure, and update early when you learn things that change the picture.