There’s a hilarious answer to the question Why are software development task estimations regularly off by a factor of 2-3? floating around now. Hilarious, deeply knowing, but not terrible accurate or actionable.

But buried in the comments was this gem from Neil K, which I’m going to quote, in it’s entirety, for truth (Neil has, after all, seen more sausage getting made at more of the places whose tools you use then nearly anyone):

This is really good, but if I can offer a suggestion — the analogy could be even more apt with a slight shift. Currently it only shows how people go wrong when they develop software in a naive way — by starting at the beginning, and coding each step to final quality, in order. The story, as written now, makes it look like writing software is just an impossible slog and nobody can do it.

The truth is, software is research. It’s a matter of discovering the solution, not plodding through it. This is implicit in your story, because they keep encountering unexpected problems. But let’s make it explicit.

Imagine, instead, that our intrepid pair is charged with mapping the coastline of California from SF to LA. Mapping is more like software development because it involves discovery, and getting things right at multiple “points”.

The naive mappers start off from SF and it all fails exactly as you outline. A more clever pair of mappers instead decide to hire a boat, and map just a few points on the coastline precisely, just to get a rough estimate, and to survey the coastline for the tricky places. Then they know where to apply their efforts — an intern can be hired to pace out some of the easy bits, and a team of well-equipped hikers can be brought in to handle the hard parts.

They can even stop when they have a map that is just good enough.