The construction analogy
I’ve always been of the opinion that software construction is not like physical construction. Or, rather, that the construction part, analogous to hammering two-by-fours together when building a house, is running the compiler. And, of course, you rarely tear a house down and rebuild it over and over, until you get it right. Therefore, software development is nothing like mechanical construction.
Except, of course, when it’s very much like mechanical construction.
I thought that it was decided long ago that writing code was design, though those who like to call themselves architects still like the metaphor to justify a phasist approach with high importance given to their chosen role. The discussion isn’t over, judging by the activity on the blogosphere. The most interesting thing I see is Mishkin Berteig’s interview of Alistair Cockburn about his house renovations. Alistair describes the agile and iterative approach he and his contractor have take with these renovations. Very interesting stuff!
Steve Berczuk and Ben from Refactr say that their experiences with housebuilding echo their experiences with software project management. We’ve also got James Shore and David Anderson and Johanna Rothman telling us how software development and building construction are completely different. And we’ve got the Poppendiecks and Matisse Enzer and Glen Alleman telling us they’re similar.
The funny thing is, these people are pretty much in agreement once you avoid the equation of (writing code == physical construction) and treat it as part of the design. And they’re particularly similar in many aspects of project management, in spite of the rosy view of the building construction industy by software managers. And, of course, it’s a metaphor or analogy. It’s not exactly the same, at all. The similarities and differences can be used to illuminate, but not to prove anything.
As we go through our housebuilding project, I want to use examples from that to illustrate issues in software development.
Thanks for mentioning the interview. I’ve also written a more extensive piece a few years back on Kuro5hin: http://www.kuro5hin.org/story/2003/3/13/211831/159
It’s a little dated, but still has lots of good fodder for the argument!
Nice to see someone else mulling over this analogy. And especially good to see someone understand that, as you put it “The similarities and differences can be used to illuminate, but not to prove anything.”
For me, the more general analogy is that *making things* of all kinds is a pretty consistent process, and that all the different ways of making things can inform each other.
In the hammer and nails construction analogy, the design occurs in the design phase and rarely deviates during actual construction. In coding, the design is done up front and is improved upon in every phase of the coding process.
Hi, Owner Builder,
Perhaps you haven’t been paying attention to others, but neither of these are always the way you describe. In my experience, a house is rarely completed without changes to the design during construction. Things are learned along the way. And in coding, it’s possible to do quite little design up front, doing just enough all along the way. In fact, this is somewhat possible with construction, given that many details are not structural necessities. With software, it’s possible to change even basic structural components at minimal cost.