Kellan Eliot-McCrae asked me to make a home for this on the web, so I did.

A few years ago, someone asked Quora “Why are software development task estimations regularly off by a factor of 2-3?” Michael Wolfe wrote a very entertaining answer comparing software development to a hike along the coast of California, which he has since copied to his own website. What seems like a pleasant ramble turns into a death march. Unexpected difficulties arise, commitments are broken and broken again, and friendships are destroyed.

The answer was deservedly upvoted by over ten thousand people, but I felt there was something missing, so I replied:

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.