How to Estimate Software Development Time Without Lying to Yourself

In a 1994 psychology study, students predicted their honours theses would take about 34 days. The actual average was 56 — a 64% overshoot. Fewer than half finished even by their own most pessimistic estimate, and these were people who had missed deadlines before. They knew their track record. They just couldn't use it.

If you've ever told a client "two days" and delivered in a week, congratulations: you're normal. They're wrong because the part of your brain that imagines the work can't see the work. There is a way to estimate that survives contact with reality — but it starts with admitting your imagination is the least trustworthy tool in the room.

Your brain estimates from the inside

Daniel Kahneman and Amos Tversky gave this a name in 1979: the planning fallacy. When you picture a task, you picture this task — its specific steps, its unique shape. You walk through the happy path in your head, and everything goes smoothly, because it's your imagination and you're the director. What you don't picture is what always happens: the migration that breaks, the API that lies, the afternoon lost to a dependency you didn't know existed.

Psychologists call this the inside view. The alternative is the outside view. It ignores the specifics of this task and asks a dumber, better question — how long did similar tasks take last time? It treats your history as data instead of your imagination as a forecast.

The numbers hold up everywhere. An MIT student tracked 559 tasks over nine months: actual hours averaged 1.7 times the estimates, worst for writing and coding. Bent Flyvbjerg's survey of 258 large projects found overruns averaging 28 to 45 percent — and forecasts hadn't improved in 70 years. This isn't a junior-developer problem. It's a human problem.

Early estimates aren't wrong — they're wide

The model says estimates made at the very start can be off by a factor of four — in either direction. The cone narrows as you research and pin down scope, mostly during the first 20 to 30 percent of the project.

The brutal implication: the problem isn't the estimate, it's the commitment. Committing to a ship date at the wide end — error factor 2x to 4x — is what kills projects. McConnell's rule: estimation's purpose isn't predicting the outcome; it's figuring out whether the target is realistic enough to steer toward.

So: never promise a date from inside the wide end. When someone demands one, give a range and say what narrows it. "Two to eight weeks — I'll know which by Friday, after I spike the auth flow" is honest. "Four weeks" is a coin flip wearing a tie.

The method: break it down and mine your own history

In 2007, Joel Spolsky published the scheduling system his team at Fog Creek had been using for a year: Evidence Based Scheduling. Two unglamorous ideas do all the work.

First, break every estimate into tasks of 16 hours or less. A schedule measured in days or weeks lets you skip the thinking. If "implement photo editor" is one three-week line item, you haven't designed it — you haven't enumerated the subroutines, the dialogs, the edge cases. The 16-hour cap forces you to design the feature step by step. Small tasks are easy to estimate because you've done them before. Three-week blobs are easy to get wrong because you haven't thought about them at all.

Second, track estimate versus actual and compute your velocity — estimated divided by actual time per task. Almost nobody is the "perfect estimator" at 1.0. Most developers get the scale wrong but the relative estimates right: everything takes longer, but consistently, with velocities clustering around 0.5 to 0.7. After a few dozen data points, the argument ends. An 8-hour estimate from someone whose velocity is 0.6 is a 13-hour task. That's not pessimism; it's arithmetic on your own proven optimism.

The clever part: keep the clock running through interruptions. Meetings, context switches, rescuing a teammate's environment — don't carve them out as separate line items. Leave the timer on. Interruptions then show up automatically in your velocity history. You never have to quantify the chaos of your workday; your track record already contains it.

Two more rules for the team wiki: only the programmer doing the work can create the estimate — a schedule handed down by management is fiction with a deadline — and charge bug-fix time back to the original task. When a bug surfaces, the time belongs to the task that introduced it. Your history then predicts fully debugged code, not code that compiled once.

The outside view: ask your past self, not your imagination

Evidence Based Scheduling is the full system, but you can start today with the poor man's version: reference class forecasting. Before estimating the new task, write down three to five similar tasks you've done and how long each really took. Anchor on that list, not on the plan in your head. Researchers found this genuinely improves forecast accuracy.

For single tasks, the classic three-point estimate does the job in thirty seconds: (optimistic + 4 × likely + pessimistic) ÷ 6. The formula's real function is forcing you to have a pessimistic number — the one your inside view would rather skip.

And the simplest habit: for every task you estimate this month, write the estimate down and add the actual when you're done. No ceremony. After twenty or thirty tasks, your personal multiplier appears on its own. From then on your estimates correct themselves,

When you genuinely can't estimate, say so — with a range

Counter-argument: some work is genuinely unknowable — novel research, integrations with systems you've never touched. Pretending otherwise is how two-week spikes become two-quarter epics.

The honest move is a range, not a point. "Two to six days, most likely three" tells a manager something real: the width of the range is the size of your ignorance, and that's information they can plan around. A single confident number hides it. And if a manager badgers you into narrowing the range, the data is corrupted — a range only works if the person giving it isn't punished for its honesty.

Sometimes estimating the whole thing is the wrong goal. At the wide end of the cone, the valuable question isn't "how long will the project take" — it's "how long until we know." Buy the answer with a spike: a day or two prototyping the hardest part, and your 4x-wide cone is suddenly 1.5x wide.

What to do this week

• Never estimate a task longer than 16 hours. Break it first. If you can't break it, you haven't designed it yet — that's the real finding.
• Write estimates down next to actuals. Twenty data points and your personal multiplier emerges. Multiply every future estimate by it.
• Give ranges, not single dates. "50% by Friday, 90% by next Wednesday" is a schedule; "Friday" is a wish.
• Don't commit at the wide end of the cone. Commit to the date you'll know the date, and attack the biggest uncertainty first.
• Charge debugging to the task that caused it. Bug fixes aren't overhead — they're the tail of the original estimate.

Your estimates will still be wrong. That's Hofstadter's Law — it always takes longer than you expect, even when you account for it. The difference is that now they're wrong on purpose: wrong by a known factor, in a known direction, with the uncertainty priced in. Nobody stops being believed over "two to six days, most likely three" that took four. They stop being believed over the confident "two days."

References

• Joel Spolsky, "Evidence Based Scheduling," Joel on Software, October 26, 2007 — joelonsoftware.com/2007/10/26/evidence-based-scheduling
• Roger Buehler, "The Planning Fallacy: An Inside View," Society for Personality and Social Psychology — spsp.org/news-center/character-context-blog/planning-fallacy-inside-view
• The SilverLogic, "Understanding the Cone of Uncertainty in Agile/Scrum," October 2023 — tsl.io/blog/understanding-the-cone-of-uncertainty-in-agile-scrum
• Kahneman, D., & Tversky, A. (1979). "Intuitive Prediction: Biases and Corrective Procedures," TIMS Studies in Management Science, 12, 313–327.
• Buehler, R., Griffin, D., & Ross, M. (1994). "Exploring the 'planning fallacy': Why people underestimate their task completion times," Journal of Personality and Social Psychology, 67(3), 366–381.
• Flyvbjerg, B., Garbuio, M., & Lovallo, D. (2009). "Delusion and deception in large infrastructure projects," California Management Review, 51, 170–193.
• Steve McConnell, Software Estimation: Demystifying the Black Art, Microsoft Press, 2006.