ConstructionAnalogy

August 20, 2008
see DevelopmentAnalogies

see also RethinkingConstruction, TheInevitabilityOfGoodEnough

The analogy between software development and physical construction comes up all too frequently.

Usually I come across software developers who write about how the analogy breaks down. BretPettichord has some interesting comments contained in these entries about how the analogy holds up.
I've often taken exception to the common metaphor of software as a construction project, but i'm realizing that the use of this metaphor suffers as much from an inapt analogy as it does to an idealization of how construction projects develop.

[The architect] assured me that i really did need to plan everything in advance, otherwise i'd be subject to onerous change fees. He assured me that any contractor would take advantage of any changes of mind that i had as a way to boost his profits.

I've changed my mind plenty of times, and it hasn't cost me a cent. My contractor assumes that changes will be made. He wanted to make a building that i was happy with and that looked good and would sometimes suggest changes himself.

Actually, i have been charged one change fee. I moved the bath room after the plans had been drafted and my architect charged me to redraft them.



Joel chimes in with a quick comment supporting the position that the analogy is a good one only because neither industry is good at schedules and budgets, and then he linked to this great article (Poppendieck) to find out what the construction world thinks of the analogy (hint: they agree with Joel).

Peter Lindberg has some personal notes on a book called “How Buildings Learn”, which seem to also support the position that construction and software have plenty in common, because construction is more fluid than seems obvious.



Dave Hoover posted about another comment about the analogy:
To paraphrase Albin, if designing, constructing, and maintaining buildings was like software development, building architects would be getting requests to have entire floors removed or added and additional structures appended onto the building.

The sidebar went on to note that urban engineering might be a better metaphor for software development, where engineers and planners receive requests for new housing developments, reducing traffic congestion, and connecting adjacent communities. Like any metaphor, Albin notes, this one also has limitations, but it certainly feels more applicable to me.



GlennVanderburg adds another entry here, with his interesting bridge engineering post:
Every now and then I hear someone compare software development to bridge building. ... the implication is clear: bridge building is predictable, rote, unexciting, very manageable work, and software development is not. The only difference is whether the speaker likes software development the way it is, or wishes it could be different.

I think both positions are misinformed. ... In my experience, software developers tend to have an idealized, unrealistic view of what “real engineering” is like.



CodeIsTheDesign references the classic “What is Software Design?” article. That article has always made me wonder what sorts of physical designs would exist if one could go from blueprints to a final building in 30 seconds -- walk it through -- then tweak the blueprint, tear the building down and build it again.

tags: ComputersAndTechnology
comments powered by Disqus