Software Estimates Are BS
Uncertainty should be acknowledged, not hidden under the rug.
Note for non-developers: This post deals with details of software development, but the underlying ideas apply to any creative work that involves communicating timelines and dealing with uncertainty. If you work in a different field, I’d love to hear about what estimate analogues or alternatives you use.
Common wisdom has it that developers suck at estimating. But the reason estimates are hard has little to do with coders. It’s rooted in the creative nature of software development.
Writing software is a process of problem solving. Solving a problem requires knowledge creation through conjecture and criticism, trial and error.
As Karl Popper and David Deutsch taught us, we cannot predict the content of future knowledge. If we could, then we would already possess that knowledge.
In the same way, we cannot predict how long it would take to create new knowledge. If we did, we’d already know how to create it.
Asking a programmer how long it will take to build something is akin to asking a researcher how long it will take to discover a new scientific theory. It’s something that cannot be answered with confidence.
Granted, there are projects where the problem to solve is not novel and devs can give a relatively accurate ETA. For example, in my day job as a mobile infrastructure engineer, I have set up continuous integration for so many new apps that by now I can tell with some confidence, “I’ll do it within a day.”
But even then, there are always surprises: a vendor update or an API change may require tooling adjustments, and you won’t know how long that takes until you’ve done it.
So, overall, estimates are bullshit.
They are no more than prophecies. They’re stage props we use to pretend software teams can run like assembly lines.
But an “it’ll be ready when it’s ready” attitude won’t get you far in business. There are, after all, real world constraints of budget, window of opportunity, and clients’ patience. We still need ways to coordinate over timeframes. Besides, teams and individuals need structure and accountability.
Here are two approaches that account for the unpredictable nature of knowledge creation without giving up on a structured schedule.
Probabilities, Not Estimates
In his book Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency, Tom DeMarco advocates acknowledging uncertainty and being upfront about risks.
He proposes using risk diagrams to model estimated time of project completion.
This risk diagram is an explicit declaration of uncertainty. It shows the relative likelihood that completion will happen at any given time. The area under the graph between any two dates represents the likelihood that the project will complete during that period.
I like this approach because it’s more intellectually honest and accurate than producing a single value. It also helps other parties involved with the project to plan for different scenarios.
Fixed Deadlines, Flexible Scope
Another approach I really like is the one championed by 37signals, where teams work in cycles with fixed duration but variable scope.
As founders Jason Fried and David Heinemeier Hansson describe in It Doesn’t Have To Be Crazy At Work:
Another way to think about our deadlines is that they’re based on budgets, not estimates. We’re not fans of estimates because, let’s face it, humans suck at estimating. If we tell a team that they have six weeks to build a great calendar feature in Basecamp, they’re much more likely to produce lovely work than if we ask them how long it’ll take to build this specific calendar feature, and then break their weekends and backs to make it so.
A deadline with a flexible scope invites pushback, compromises, and tradeoffs—all ingredients in healthy, calm projects. It’s when you try to fix both scope and time that you have a recipe for dread, overwork, and exhaustion.
Earlier, I compared software development with science research because both endeavors require creative problem solving. But developers have the advantage that software is malleable and iterative. You can’t iterate your way to the successor of General Relativity. It’s either done or it isn’t. But you can solve the problem of building a new calendar by shipping a simple implementation in six weeks, then a better implementation six weeks after, and so on.
Fixing a delivery date and being flexible on the scope of what will be delivered bypasses the whole issue of inaccurate estimates. It embraces uncertainty and encourages error detection and correction.
I find risk diagrams and fixed deadlines with flexible scope better alternatives to story points, t-shirt sizes, and other estimate tracking systems.
Rather than ignoring the inherent unpredictability that comes with the job, they front load and account for it. They help us avoid fooling ourselves.
Does your team use estimates? What’s your experience been? If you’ve found a better alternative, shared it in the comments so we call all learn from it.