Software Isn't a House

I came across a discussion recently (I can't remember where) about how the typical comparison between writing software and building a house is flawed. The article was pretty compelling, pointing out that because a building is something very tangible and physical, it doesn't actually compare very well to software.

For instance, you can't refactor a building. Replacing the plumbing would be too costly. And yet, such activities are common place with software. It is here that the metaphor fails to capture the essence of software. And because of this failure, the metaphor perhaps puts a greater emphasis on upfront design than is truly needed.

Which is where I think agile software development practices come in. These practices favor the approach of designing as little as you have to and coding as soon as you can. When you come to a point where refactoring is needed, go ahead and do it. Constantly modify the code to make it better, but make it only as complicated as it needs to be. Could you imagine building a house this way? Getting halfway through pouring the foundation only to realize that there's a better way. It would be ludicrous for housing projects to proceed in this manner and yet the house metaphor is one of the most common techniques used to describe software development.

So what metaphor is more appropriate? Therein lies the problem. I haven't read of one and I haven't come up with one on my own. Hopefully, in the not so distant future, inspiration will strike. I'll be sure to write about it here when it does.