Estimating software is hard. It doesn't matter how much planning you do, how much detail you devote, or how much experience you have, you are still likely wrong more than you are right. Nearly every book on software development includes some anecdote about a government or corporate software contract that went way past the deadline and cost way more than the initial budget.
While we try really hard to provide decent estimates (we don't do quotes), just like everyone else, we have a far from perfect track record. In this post, I want to try to explain why estimating software is so hard and some of the tools we use to counteract this.
A huge pile of rocks
Imagine you have a huge pile of rocks you need to move from your front yard to your back yard. You get a wheel barrow, put on some work gloves and settle in for a day of backbreaking work. Your task is simple: put rocks in the wheelbarrow without overloading it.; wheel the rocks to the back yard; repeat until the pile is gone.
This is a good analogy for software development. In software development, our pile of rocks is what we call the backlog. Each rock represents a "story" or individual piece of the software to be created.
With this analogy in mind, let me give you three reasons why it's so hard to estimate software development:
Reason 1: Dependence—you don't see the rock until you move other rocks.
Imagine you are working on your pile of rocks, and you move the first layer of rocks, only to see a really big rock below it that was completely covered. The only way to see that rock was to move the layer covering it. You had no way of knowing it was there until you moved the rocks on top of it.
This kind of thing happens from time to time in software development. Often, you don't realize how complicated something will be until you actually get fairly deep into the work. Sometimes, you don't even realize something needs to be done until you have done all of the stories surrounding it.
For example, imagine building an image uploader on a form only to realize that the users were uploading images that were the wrong aspect ration. Now you don't just need an image uploader, you need a way to crop an image or shrink an image. You have to decide whether to do this automatically on the server or provide some kind of front end tool that allows the users more control. Either way—you've just created a lot of work you didn't see at first.
These kinds of things are almost impossible to foresee and estimate for.Similar to this is another reason it's hard to estimate software...
Reason 2: Complexity—when you try to move the rock, you realize it's way bigger than it looked.
So you are working on your rock pile and you reach down to grab what seems like a normal sized rock, only to realize what you see is just the tip of the iceberg. It's just a small piece of a huge rock that is buried under the pile. You realize you are going to have to save this one for later and probably get out the pry bar or get a neighbor to help.
In a dev project, sometimes a task seems to be small until you start working on it. Then it ends up being huge. The small story you imagined was just the tip of the iceberg ended up being a ton of work. Very often, small tasks are actually huge and big tasks end up being fairly simple. The key is that its really hard to see which is which until you get into it and this makes it really hard to estimate accurately.
One more reason estimating software is so hard is...
Reason 3: Abundance—after you move the big rocks, you find a ton of tiny rocks that need to move.
You get all your big rocks moved. What started as a huge pile is now just a single layer of tiny rocks on the ground. But there are soooo many of them, and your back hurts. You realize this is going to take a while.
Very often in projects, it's not the hard stuff that takes the most time. It's the seemingly unending list of minor tweaks and features that comes at the end of a project. None of these things take a lot of time, but when you factor in context switching, a dozen thirty minute tasks is still a full day of work for one developer. It's likely there are dozens and dozens of these left at the end of a project.
When you are first planning the project—all of your focus is on the big stuff—the main features of the application. It's really easy to completely forget about the list of minor things that need to be done and not include them in an estimate.
Solutions for estimating
There are a few things we try to do to help with estimating. We aren't perfect, but these really help:
- We don't have any conversation about how much something will cost until we've fully explored the problem in a one day, on-site discovery meeting. Trying to give a loose estimate without discovery is like asking a contractor how much will a house cost. "Is it a tiny home, a two bedroom ranch, or a mega-mansion?" We won't know until we go through discovery.
- We never give a quote. We charge for our work bi-weekly and have several calls a week to discuss progress. If we quoted 30 hours and sent a bill on a project that really took us 90 hours our relationship would fall apart. If we billed you 90 hours on a project we did in 10, you would lose trust in us.
- We break the project down into stories and try to estimate each story. We give each user story an estimate and then group the stories and compile an estimate for each group. We use t-shirt sizes for this (S, M, L, XL). Each t-shirt size corresponds to an hour range (S is 1-3 hours, L is 6-10).
- We give a small, medium, and large range for the project based on the t-shirt sizes of the stories. We usually end up somewhere in the middle, but we've been pretty close to going over once or twice.
- We strongly encourage our clients to limit the scope of the first version of a product. Focusing on one key piece of functionality that solves the core problem. Anything we can cut that doesn't serve that core function should be cut and left for a future version.
Using these methods, we've been able to give our clients pretty decent estimates. But they are never perfect, and they never will be. We just won't know exact figures until we start moving rocks.