Software Estimates Suck

People suck at estimating how long a task will take. We are often off by a factor of two or more when estimating seemingly simple everyday tasks, like running errands, so imagine how bad we are at estimating complicated tasks like building a new software feature.

Now imagine estimating a set of features instead of just one, or even a whole project upfront. Time estimates in such cases quickly become pointless. The biggest challenge in my opinion about estimating a whole project upfront is that you don’t know the complexity of the problems you are trying to solve until you actually start solving them. Moreover, those problems you are trying to solve never stays the same. Requirements change, problems get more complex and projects often suffer from feature creep.

You’ll be inclined to think that if a task is very similar or identical to a task you have done before, then it’s going to take exactly the same time. You’re wrong. It’s very unlikely that 2 tasks are identical. Chances are the requirements are going to be slightly different, design will change a bit, you’ll be working with different people, etc. These are all things that will increase (or decrease) the time required to finish the task.

One more thing that always make time estimates highly inaccurate is the time needed to fix bugs. You can’t leave that time out, but you also can’t estimate how long it will take to fix bugs you don’t have yet, and there’s no one-size-fits-all time frame that you could assign to bug fixing that would work for all tasks. Sometimes you spend days debugging a single nasty bugs, how could you estimate that kind of stuff?

Moreover, people always ignore the time needed for daily communication. A lot of friction may happen in human interaction, especially if it’s across teams. There is usually misunderstanding and confusion that leads to a lot of delays.

So estimates suck, but they are a necessary evil,  so now what? I like to take Jason Fried’s and David Heinemeier Hansson’s advice from Rework. Never estimate a bulk of tasks. It’s much easier to divide into smaller tasks and put estimates separately. So break the project into many small projects. Your estimates will still be wrong but you’ll be a lot less wrong.

Also, if you’re working in a large development team, you’ll often be surprised at how different estimates from multiple people for the same task could be. My favorite way of dealing with those situations is to play a game, a Planning Poker game. In my opinion, it’s the most efficient way to get people to agree on a reasonable estimate for a single task.

One last thing, never give in to your Pointy-haired Boss‘s request to do the same task in half the time because “you’re a smart engineer, you can do it”. It just doesn’t work that way. While your estimates are probably wrong, they are still your guess of how long it would take to finish that task. No one can simply jump in and ask you to finish in less time, unless they have a very good reason, and of course an arbitrary deadline is never a good reason.

How do you deal with estimates in your team? Let me know in the comment below.