I read Mishkin Berteig’s Kuro5hin article The Software Construction Analogy is Broken, and I’m not sure I agree with what he says, but I can’t explain what I’m having problems with. I’ll just quote what I underlined as I read it and see if it gets any clearer:

In fact the processes and techniques used by construction are heavily influenced by the requirement to build in place – to make it right the first time. [–––]

Finally, this difference [between software and construction] has an artistic component. Practitioners of building architecture are inspired to reach a completely different aesthetic goal than practitioners of software creation. The construction industry cannot help the software industry make beautiful software. [–––]

In a construction project there is one shot at making an essentially immutable physical structure. This immutability […] is the central motivator for the process used by the construction industry. The only process or methodology that makes sense for building construction is the “waterfall” [–––]

Software creation is not subject to the same constraints as construction. The intellectual nature of software means that it allows far more creative freedom. [–––]

Building architecture and function are closely intertwined, software architecture and function are nearly independent. [–––]

Software is fluid. It is possible to build software before even any formal requirements have been gathered. And that same ad-hoc software can then gradually be built upon [–––]

Iterative development methodologies attemt to address this fluidity with various degrees of success but the very fact of iteration breaks the analogy with construction. [–––]

Software is incredibly abstract and often very arbitrary. […] Examining another programmer’s code with a mind to using it (let alone modifying it) is not a simple exercise. [–––]

Those who promote the construction analogy in the form of component based development overlook the simplicity and intuitiveness of “components” in construction. [–––]

Construction projects go over budget, sometimes horrendously. […] The construction industry has re-usable patterns, idioms, and parts, but there is a very clear dividing line between the intellectual constructs and the physical constructs. The as-built plans are always different from the architectural plans. […] It starts to sound like maybe construction projects might be just as bad off as software projects. [–––]

Unfortunately [Extreme Programming] is missing a coherent analogy to some other realm of human experience. Occasionally mention is made of the creativity and skill of the programmer. This might lead us to an analogy in the world of media.

The amazing thing about software is that each new software program or system is a completely new medium of expression. […] No one would debate that sculpture and handwriting area two different media. Therefore software creation is the process of creating new medias [sic!].

This analogy of media creation is anticipated by Marshall McLuhan’s famous quote: “The Medium is the Message.” And so software creation is really communication as well. […]

First, I don’t think I understand the McLuhan reference, but I think the software-as-medium idea is worth looking further into. Then, I don’t think it rings true what he writes about a software system not being clearly separated from the ideas behind it (if I understand him correctly); about “software architecture and function [being] nearly independent” – I also have some problems with the idea that the fact that buildings are immutable and built “once” explains why the process of construction won’t work for software.

Now, I do think that many ideas could be adopted from the field of building architecture, but then one must realize that it’s the process of developing the idea of the building, discovering it by doing sketches, building temporary models, and so forth – all the work that precedes the creation of the final models that are to be shown to the prospective customers – that is the most similar to software development.