Your Software Estimates Are a Lie (And Everyone Knows It)
Software estimation is broken. Not because developers are bad at it, but because the entire framing is wrong. Here's how to stop pretending and start planning honestly.
Every software project starts with the same ritual. Someone asks “how long will this take?” An engineer stares at the ceiling, does some mental arithmetic involving best-case scenarios and optimism, and says “about three weeks.” Everyone nods. The project takes eight weeks. Nobody is surprised, but everyone acts like they are.
This isn’t a failure of estimation. It’s a failure of honesty about what estimation actually is.
Why estimates are structurally broken
Software estimation isn’t like estimating how long it takes to drive somewhere. Driving has a known route, known speed limits, and predictable traffic patterns. Software development is more like estimating how long it takes to find something you’ve never seen in a building you’ve never been in.
The core problem is that most of the work in software is discovering what the work actually is. You think you’re building a login page. Then you discover the client needs SSO. Then you find out their identity provider has a quirk that isn’t documented. Then the designer changes the flow because user testing revealed confusion. Each of these is reasonable. None of them were in the estimate.
This isn’t scope creep. It’s reality asserting itself. And no amount of upfront planning eliminates it, because the unknowns are genuinely unknown until you start building.
The estimation paradox
Here’s the uncomfortable truth: the point in a project where you know the least is exactly when you’re asked to estimate. At the start, you have a vague brief, some assumptions, and whatever the last similar project taught you. By the time you actually understand the problem well enough to estimate accurately, you’re 80% done.
This is why experienced engineers pad estimates. It’s not laziness - it’s pattern recognition. They’ve been burned enough times to know that the confident estimate is always wrong, so they add a buffer for the things they can’t see yet.
The three estimation lies
Lie 1: “We can estimate this if we plan enough upfront”
The waterfall dream. Spend two months writing detailed specifications, break everything into tasks, assign hours to each task, add them up, and you’ll have an accurate timeline.
In practice, detailed upfront specs create the illusion of certainty. You’ve written 40 pages describing a system that doesn’t exist yet, and everyone treats that document like a contract. Then reality shows up. The API you planned to use is deprecated. The data model doesn’t handle a common edge case. The user flow that looked clean on paper is confusing in practice.
The spec didn’t reduce uncertainty. It just made everyone more confident about the wrong plan.
Lie 2: “Story points fix this”
Story points were supposed to separate effort from time, giving teams a relative measure of complexity. In theory, it’s a clever abstraction. In practice, most organizations immediately convert points back to hours, which defeats the entire purpose.
Worse, story points create a false precision. A task estimated at 5 points feels meaningfully different from one estimated at 8 points. But the reality is that both estimates are rough guesses, and the difference between them is noise, not signal.
The meetings where teams debate whether something is a 5 or an 8 are time that could be spent actually building and learning.
Lie 3: “We were bad at estimating, but we’re getting better”
Teams track their estimation accuracy and try to improve. This sounds rational. But estimation accuracy doesn’t improve linearly because each project introduces new unknowns. You might get better at estimating the kinds of tasks you’ve done before, but the tasks that blow up timelines are always the ones you haven’t done before.
Getting better at estimating familiar work is useful but limited. The expensive surprises come from unfamiliar territory, and by definition, you can’t estimate what you don’t know.
What actually works
Timebox instead of estimate
Instead of asking “how long will this take?” ask “what can we accomplish in two weeks?” This flips the dynamic entirely. The time is fixed. The scope is flexible. The team focuses on delivering the most valuable work within a known window.
This isn’t a trick - it’s an honest acknowledgment that time is the only variable you can actually control. You can’t control how complex the problem turns out to be. You can’t control what surprises emerge. But you can control how long you spend before stopping and evaluating.
Ship in slices, not layers
Instead of building the complete backend, then the complete frontend, then integrating - build one thin slice of functionality end-to-end. A login flow that works. A single report that generates. One transaction that processes.
Each slice teaches you something real about the system’s complexity. After two or three slices, your understanding of the remaining work is dramatically better than any upfront estimate could have been.
Use ranges, not numbers
If someone demands an estimate, give a range. “This will take between 3 and 8 weeks.” The range communicates uncertainty honestly. If the range is too wide for planning purposes, that itself is useful information - it means the project has too many unknowns to plan with confidence, and you should reduce scope or do a spike first.
A single number estimate communicates false precision. A range communicates reality.
Separate discovery from delivery
The highest-risk phase of any project is the first 20% - where you’re figuring out the architecture, hitting unexpected constraints, and discovering what you didn’t know. Build in an explicit discovery phase. Spend a week or two exploring the problem space before committing to a timeline.
After discovery, your estimates will be dramatically better. Not perfect. But grounded in actual knowledge instead of assumptions.
The cultural problem
Estimation isn’t just a technical problem - it’s a trust problem. Developers pad estimates because they’ve been punished for being wrong. Managers demand estimates because they need to plan budgets and timelines. Both sides know the numbers are fiction, but nobody says it out loud.
The fix is cultural. It requires leaders who understand that uncertainty is inherent, not a sign of incompetence. It requires teams that can say “we don’t know yet” without that being career-limiting. And it requires planning processes that accommodate reality instead of demanding that reality conform to a spreadsheet.
The best engineering organisations we’ve worked with don’t have better estimators. They have better systems for dealing with the fact that estimation is unreliable. They plan in iterations, ship incrementally, and adjust course based on what they learn rather than what they predicted.
The honest conversation
Next time someone asks “how long will this take?” try responding with: “Here’s what we know, here’s what we don’t know, and here’s how we’ll find out.” It won’t satisfy the part of the business that wants a number in a cell. But it’s honest. And honest planning, even if it’s uncomfortable, always beats confident fiction.
The goal isn’t to get better at predicting the future. It’s to build systems that don’t require you to.
At IndieStudio, we plan projects around timeboxes and discovery phases rather than fictional timelines. If your last project blew past its estimate, let’s talk about a better approach.