Why software estimation is like a road trip

One of the hardest things for a product team to do is estimate how long it takes to build something. This inability to provide accurate timings can be frustrating for stakeholders, which is completely understandable if they have their own goals and timelines to adhere to. When faced with this challenge, I like to compare our work to going on a car journey.

Let’s start with the short, everyday journey (picking your children up from school for example). Since you know the route and have done it frequently, you can be pretty accurate in your timings. There are however those few occasions when something unexpected happens, like an accident or roadworks, and your journey is delayed.

This is similar to software development. There are those frequent, short tasks that you can predict with high accuracy. However, there is no way to guarantee it 100% of the time. People fall ill or they have to move to a more pressing and unexpected task, for example.

What about the journey that is a bit longer and not quite so frequent, like visiting your family or friends out of town? If you have done the journey often enough, and it isn’t too far away, then you can say with some level of accuracy how long it will take. However, there is still the risk that something unexpected will happen, and as the journey is that little bit longer, the chances of that happening are even greater.

This is the same for software development, the longer the task, the less confident we can be in our estimates. It is more likely that something will block our progress, even if it is a task we have frequently undertaken.

How about those long journeys, the ones we have done infrequently, or have never done before? Trying to estimate how long it will take is incredibly hard, especially if it is for the first time. Thankfully, with the use of our apps, we can get some idea of the journey length. But even then, the length of the journey means there is a much higher risk that something unexpected happens and the initial estimate is wrong.  

This long, infrequently travelled journey is the bulk of our work in software engineering, particularly when it comes to innovation. Most of the time we are building something significant for the first time. Therefore, the risk that something unforeseen happens is high. One solution is to break the journey down into smaller chunks. This is like creating our own GPS of the trip, where you map the shortest route road by road. Even with this approach, it is likely that unforeseen incidents will still happen. A road that was initially clear may become busy or blocked some hours later. The more roads we journey on, and the longer the trip, the more likely our journey will be delayed.

So, if you are ever wondering why it is so hard for product teams to provide accurate estimates, then think of those long car journeys you go on, and how hard it is to accurately predict the arrival time.