|Welcome to the Monastery|
Thanks for the support.
Like all symbolic language, there are inconsistencies in this metaphor. However, I find that sometimes a look outside the immediate surroundings of the topic is necessary. There's a psychological trick here in that removing one's thoughts from the topic at hand for a moment can help one focus more clearly once the mind returns to that track (train metaphor -- watch out). The fact that some semblance can be drawn helps serve the point, but it's far from the only reason for the comparison. I could have just as readily talked about how cute my step-nephew is for a paragraph before moving on to the topic, but I thought the metaphor could serve dual purposes.
It's true that at some point comprehensive software design is almost code and that abstract code is nearly a design. I think there's another point that separates building construction and software development even more, though.
I find that the biggest difference from building construction is because there's so little cost to moving code around. In building construction, it would be wonderful to pull a wall out here and put it back in over there. Unfortunately, there's a lot of physical labor involved, the materials are usually damaged during the remodeling, and the structure may not be as sound afterward. With software, it's much quicker and easier to move whole chunks of code from one place to another, change the interfaces, and generally muck about.
This is in large part because software is abstract, but not necessarily because it is close to the same level of abstraction as the plan. Actually, I'd bet lots of architects are using the 3D building design software on the market to do with virtual copies of buildings what we do with code. Think of it as a visual integrated development environment using pluggable modules to create a value-added design by pointing and clicking, with certain details left to hand-written code(s)...
Now that I've almost choked reading my last buzzword-riddled sentence, let me say that we'll probably never find a metaphor that fits programming better than devising a meal recipe. There are many ways to compare parts of software development to parts of other ventures, but it is so fundamentally different from everything that came before that nothing is particularly adequate in every way. Technical writing can be almost programming, and hardware design can be exactly programming, so those don't serve well as metaphors. A metaphor has to be enough alike while also enough different, and that's a fine line in any case.
Strict research science is still not a preferred metaphor for software development (as a whole) in my mind. Part of the field is certainly science (or close enough to call it that). I see far too much synecdoche surrounding programming, and I'm afraid that's not likely to end soon. Some people mistake programming for a science, while others mistake it for pure math, and others mistake a complex macro-powered server configuration for all of computer programming. This confusion needs to be defeated before the tensions surrounding the field can be released. Programming is all of these things, and none of them is all of programming.
Christopher E. Stith