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.



http://amzn.to/1JzNKyj
Steve McConnell is recognized as one of the premier authors and voices in the development community. He is Chief Software Engineer of Construx Software and was the lead developer of Construx Estimate and of SPC Estimate Professional, winner of Software Development magazine's Productivity Award. He is the author of several books, including Code Complete and Rapid Development, both honored with Software Development magazine's Jolt Award.
Check out his book