Why Software Estimation Is Hard — And How to Be Less Wrong

"How long will this take?"

The manager asks. You think. "Two weeks," you say. Three weeks later it's not done; the manager is tense, you're stressed, the team is being dragged along.

Estimates are always wrong. The cause isn't that you're inadequate. It's the nature of software hiding traps in estimation. After 13 years of getting this wrong (and slightly less wrong), here's what I distilled.

Why it's hard

1. The cone of uncertainty

When you start a project, you have 20–30% of the information you'll eventually have. The other 70–80% is what surfaces in the first week of actual work. The estimate you give is, by necessity, mostly about things you don't yet know. It will be wrong.

A classic finding: an estimate at the start of a software project lands somewhere between 0.25× and 4× of reality. So a 1-month estimate could finish in a week, or take four months. The cone narrows — accuracy improves as the project unfolds.

This is physics, not personal failing.

2. The things you don't know to plan for

You're writing a feature. Estimate: 5 days. Then:

• Third-party API has wrong docs, you spend 4 days, not 4 hours
• Existing codebase isn't shaped how you thought; needs refactor
• Test environment is broken; 1 day to fix
• Teammate is on vacation, a question can't be answered

You didn't know any of this when you estimated. You didn't plan for any of this. All of it is real.

3. Optimism bias

The brain naturally over-estimates. "This function will take 2 hours" suppresses the memory of similar functions that actually took 6 hours.

Every developer has this bias. Seniors have it less, but they still have it.

4. Estimates get treated as commitments

The moment the manager hears your estimate, it becomes a plan. Even if you say "I estimate two weeks, but it could be four," the senior team will remember "two weeks." Expectations form. Estimates aren't commitments, but they get treated as them.

This social dynamic corrupts the value of estimating. No one wants to be a "good estimator" because good estimating is a game where successes don't pay and failures get punished.

How to be less wrong

1. Give a range, not a point

Instead of "5 days" → "3–7 days." Instead of "4 weeks" → "3–6 weeks."

A range is honest. It expresses the cone of uncertainty. If the manager pushes back at first, explain: "giving a single number forces me to lie; this is more accurate."

2. T-shirt sizes (S/M/L/XL)

Hour and day precision is mostly false precision. Instead:

• S: a day or less (small fix, minor UI change)
• M: 2–3 days (medium feature)
• L: a week (large feature with integration)
• XL: 2+ weeks (something we don't yet have a plan for)

When you see XL, break it down. If breaking down isn't possible, write a 1-day spike first — get a real estimate after.

3. "Build time" + "buffer"

Give the estimate as two parts:

• Build time: writing code, writing tests. 5 days.
• Buffer: unknowns, things you'll miss, bugs. 2–3 days.

Total: 7–8 days.

People learn the buffer concept years late. Once you do, your estimates get ~30% more accurate.

4. The "first investigation" strategy

If estimating now is impossible due to unknowns: "let me spike it for a day, then I'll tell you." This is actively narrowing the cone of uncertainty.

The manager waits 1 day; the resulting estimate is grounded in real information.

5. Calibrate yourself regularly

Monday: what's reasonable for this week? Friday: what did I actually finish? The gap is your calibration data.

Three months in:

• "Estimates I called 1 day usually take 1.5 days"
• "Working with unknown APIs runs 3× the estimate"
• "I always under-estimate refactor work"

Personal calibration sharpens future estimates.

Manager communication

Estimation discipline isn't one-sided. The manager has a role.

A good manager:

• Asks "how long?" not "how many days will it take?"
• Accepts the range
• When time slips, wants to understand, not blame
• Calibrates with the team at sprint end

A bad manager:

• Says "why was your estimate wrong?"
• Treats estimates as contracts
• Blames the team when time slips

If you're working with a bad manager, protect yourself: write estimates as ranges + buffer, in writing, in email or in the ticket. Don't hand over single-point estimates.

Closing

Software estimation isn't going to be accurate. It can be less wrong.

Use ranges. Use t-shirt sizes. Add buffer. Narrow uncertainty with spikes. Calibrate yourself. With these five habits over a year you'll be noticeably better at estimation — easier on your manager, easier on your stress.

Estimation isn't a number; it's a communication tool. Conveying uncertainty matters more than producing the number.