Why estimates never work

Somewhere, right now, a project manager is compiling estimates on a software project and coming up with a completion date based on “velocity” and “scope”. When they’re done, they’ll take their completed work and show it to their boss, who will look it over, and set a “hard date” for delivering the project. There will be a team meeting, the developers will be gathered, the plan will be presented to great fanfare, and everyone will go off to work, expecting that they’ll actually meet the hard deadline in three months.

Three months will go by. The deadline will come and go. And in most cases, the deadline will be sorely missed.

You can probably guess what happens next. Executives will be furious. Project managers will blame the “lazy” developers. Developers will blame the over-zealous estimates of the project managers. There may even be a death march. At the end of it all, much if not most of the developer team will quit, the executives will vow “never again”, and the resulting project will be terrible, filled with bugs, and full of technical debt.

How do I know all this? Because I’ve seen it happen. Over and over again.

The truth is that estimates are a terrible way to determine when a project will be completed. There are four reasons why estimates fail.

Estimates are based on a best-case scenario.

When a project manager asks a developer for an estimate, they’re asking them to guess at how long something will take. The developer will use their judgement, experience, and familiarity with the project to make an estimate. But in almost all cases, these estimates are “best case scenarios”. The project manager then takes those estimates, adds them all together, and determines how long a project will take.

But what happens when the worst case comes true? I’ve worked with project managers that assume developers can do 40 hours a week of work. A sick day, a vacation, a power outage at the office or a snow storm can wreak havoc with their schedule.

Other times the developer only estimates the time needed to write the code – not to think about it. I may take 40 minutes writing a feature but spend 4 hours thinking about how it’s going to work and what it’s going to look like. If I estimate only 2/3rds of an hour, my estimate is off by 700%. Thinking time matters too.

Finally, most people are optimists. They estimate based on optimism about how long something will take. If we take that estimate as gospel, we run the risk of making a terrible mistake in our planning.

The scope estimated isn’t the scope built.

If I give you an estimate on a particular feature or task, my estimate is only good for that particular feature or task. Any changes will change the estimate. This logical, reasonable concept makes sense to most people on its face. And yet, so often it’s forgotten when we get into the nitty gritty of software work.

If a developer estimates two days for a particular task and the project manager then adds a bunch of new stuff, nobody can hold the developer to the “original estimate”. Adding stuff on will make the job take longer. Period.

“Scope creep” happens all the time. It’s common, so common that I’ve never worked on a project that didn’t have it. Yet so often the developer’s original estimate for a far smaller body of work is still used to plan the project. Is it any wonder that the final date is wrong?

Features don’t exist in a vacuum.

Features don’t exist by themselves. You don’t write a feature and have it never interact with other features. But so many estimates forget this fact. A developer will forget that a feature affecting user accounts affects every part of the application and only quote the time needed to write the new code. They forget to fix the other code that is now broken becuase of the changes.

The more massive the feature, the more impact it has on the entire system. And if an application is already built, the work is even harder. Foundational application elements are like the joists or the foundation in your house – replacing, fixing or changing the structure in a way that requires modifying these components will inevitably result in more work in unexpected areas than you otherwise anticipated.

Application development is more art than science.

To cook a steak that is one inch thick will take between 10 and 12 minutes. I know this, because I have copious amounts of experience with cooking steaks. There’s a scientific certainty that if you apply the right amount of heat for the right amount of time that you’ll get consistent results. There are many parts of cooking that are pure artistry, but there are many more that are simply chemistry.

Not so in programming. In the programming world, it’s nearly all artistry. Computer Science may be a STEM discipline in the schools, but software development is not a scientific or engineering pursuit at all.

How do we know this? Ask 100 developers to implement a function and you’ll get 100 different, unique approaches. And by “unique” I mean “completely different and novel from one another.” When it comes to many other professions, there just aren’t that many ways to do things. This is a uniqueness in the development world that’s special, but often ignored.

If you asked a famous artist, “when will that painting be done?”, you’d be told, “when it’s ready.” If you insisted on an estimate, you’d walk away with paint all over your face. And if you got an estimate and then demanded to know why the project is late, you’d be lucky to leave at all. Art doesn’t follow a schedule. Cooking a steak follows a schedule. But art does not.

But wait! What about agile/scrum/<insert development methodology here>?

There are a number of development methodologies that purport to fix the problem in a variety of ways. But they really don’t end up fixing the problem, they mask the problem by reducing the calendar time eaten by bad estimates.

Imagine that I estimate something will take 2 days. It takes twice as long, so it takes four days. If my sprint is 2 weeks long, I’ve only lost 2 days out of it. If I am consistently estimating at 1/2 the time it actually takes, I’m still delivering work on a fairly regular basis, but I’m still not estimating well.

Development methodologies were designed to reduce risk, but they don’t actually help deliver software faster. In fact, many of them come with additional overhead in providing frequent estimates, breaking up the day with stand-ups (I hate stand-ups), endless meetings and constant pressure to be right about the estimate (leading to other bad things like overtime and burn out).

So, what do we do if estimation sucks?

The answer is don’t estimate in the first place. Period. Just don’t do it.

Estimates suck. They’re rarely if ever accurate. Creating them is busy work better spent writing software instead.

So, if you don’t have estimates, how do you ship software? The answer lies in building an application that always remains stable and production-ready as new features are added, combined with the creation and implementation of small features.

The concept here shouldn’t be hard to grasp. Look at GitHub: they deploy several times a day, pushing out new features all the time. They have a solid continuous deployment process, a solid rollback process, and developers create features and ship them in a short time. Certain features are designed to be feature-flagged as off (so they don’t show up if they aren’t ready), or A/B tested.

Of course, if your app is just starting out, this can be really hard. That’s why the concept of the MVP (minimum viable product) is so important. I don’t like the MVP from a “product validation” standpoint, but I love it from a “let’s ship something quickly and iterate” standpoint.

If you’re shipping software constantly, you don’t need estimates. If a feature is taking a long time you know it, and you can work to address it by breaking it up or determining how you can declare victory sooner. Plus, your work gets shipped faster, bugs are fixed sooner, and developers are better able to move the project forward.

Estimates suck. But you don’t have to fall into the estimate trap. Instead, start shipping, start delivering, and stop driving yourself crazy with estimates that won’t be right anyway.

Brandon Savage is the author of Mastering Object Oriented PHP and Practical Design Patterns in PHP

Roderik van der Veer (@r0derik) wrote at 4/28/2015 1:27 am:

While I agree with your points, I find your conclusion very one sided. I understand your solution of not estimating might work in companies like GitHub, but it will never fly in agency contexts.

Agencies are a time based business, where an hour worked should mean an hour billed to the client. Clients will never give you a blank cheque, nor does “variable scope” means a lot less than the initial scope talks. An estimate is needed to sell projects, and estimates are needed to try and figure out what and how it can be built within the budget available. Margins per hour are not enough to pay even an overrun of 100%.

I understand that there is no real solution, and I would really like it if not estimating and just billing time and material was always possible, but unfortunately a lot of developers are stuck with this economic reality.

Tony Christopher wrote at 4/28/2015 12:07 pm:

I agree with Roderik. I work for a design and development company where the client needs to know the price before we begin the work, and that means estimates. It’s impossible to not have estimates. Even if we were to have an open project where we charged for the actual time worked we’d still have to give the client an estimated cost, and explain why it went over when it inevitably does.

Muhiyeddine wrote at 5/4/2015 10:10 pm:

This economic reality is a false reality, because we try to control something that is beyond our control.

Software engineering is like the butterfly effect: a very small change in estimate will lead to a huge change in making the project more late than expected.

The problem is more about the business managers who are not aware of this reality.

If corporates want to have hard estimates and deadlines, they only have to stop doing business in software engineering, their business model is not working.

I completely agree with this article: software engineering is an art, and the best product is impossible to tell when is finished.

(remember the 9th symphony: commissioned in 1817, Beethoven began in the autumn of 1822, and finished in February 1824)

Copyright © 2023 by Brandon Savage. All rights reserved.