Estimating how long it takes to build software – or even how much effort a sprint is – is pretty hard. Estimates often turn out to be too optimistic, and mispredictions can be pretty hard to explain to management. I know why this is so – Michael Wolfe on Quora has a great analogy (there is even an interesting discussion on Reddit), which I agree with. But I'm wondering whether there's an easier analogy.
Building a toilet
People like to equate software engineering with civil engineering, where estimates are supposedly much more accurate. While I know nothing about civil engineering, I know that building a toilet sure isn't something that can be accurately predicted.
2 years ago, I had an extra toilet built in my house. The contractor charged based on the number of hours actually worked, not based on an up-front estimate. They said that the amount of time depends on what they encounter. The initial estimate was 3 days.
On the second day, they found out that the floor they had to bore through, was much thicker than they thought. It was roughly twice as thick as what would be found on in a typical house. So boring took an extra half day.
On the third day, they bored into our washing machine's wastewater pipe. They didn't know it was there – they estimated that the pipe wouldn't be there, but it was. Fixing that took an extra day.
In this case, the wrong estimation was caused by unknown factors. If the contractor had the house's blueprints, then the estimate might have been more accurate.
A thousand pipes?
That was just one floor, one pipe. Software is a lot more complex. Imagine a floor that's 100 meter thick, with a million pipes, some of them organized logically, others entangled like spaghetti. Your job is to build a new pipe, either without disrupting the other pipes, or by fixing them afterwards.
How do you even begin? You can't estimate based on the amount of time you need to bore through 100 meters: you're sure to hit something, and how long it takes to fix that pipe depends on which pipe it is.
Maybe you can look at the blueprint? How do you even put a million pipes in a blueprint in a way that you can still read the blueprint? My guess is that the blueprint will have to be heavily simplified: it'll only show the most important things, or it'll organize various details into single groups.
While a simplified blueprint is great for broad understanding, it's not enough if you want to lay a new pipe. The details still matter. How do you find out exactly where each pipe is? You can either have more detailed blueprints; or you can choose not to, and declare that the floor itself is the canonical source of truth.
I have no idea whether a 100 meter floor with a million pipes exists. So perhaps an even better analogy is the human body. a 10 cm2 block of your body contains thousands of vessels and thousands of different types of cells. While we have a general understanding of human atonomy, everybody's body is different. When performing surgery, it's easy to hit a vessel even if you have a general understanding of where they are supposed to be, and other sorts of complications can arise.
How long does it take to perform surgery?