Matisse has an interesting post, Software is like Building Construction. He talks about iterative design and the interdependencies of people with deliverables as being common to construction and software.
In my opinion, he's not all wrong, but he's not all right. I agree that there are plenty of design-build firms who wait until the last possible moment to cement the design before building. When we remodeled our house, we used an iterative process, and yes, we incorporated the things we'd learned from earlier in the project to the later phases.
But the place where I believe the metaphor falls down is the cementing of design and the use of people. In construction, plumbers don't do electricity, electricians don't do carpentry, and none of tradespeople do any top-level design. (The general contractor might, but not the individual plumber or electrician.) In reality, in software projects, any developer can (and does) change the top-level design if things don't fit. The top-level design does not have to be finalized–ever. In fact, the more releases of a software product, the less some level of design is cemented or finalized. And, effective software people know a lot about the rest of the product, not their small piece.
Construction projects can learn from software and software projects can learn from construction. But to me they are very different in nature and the metaphor does not work as a whole.
I agree :+: I’ve seen it proposed (in many places, but none specific come to mind at the moment) that the construction metaphor in software development applies more to running the compiler than to writing the code. Writing the code is analogous to drawing the plans.
– George
I actually worked for a software company that made products for the construction industry. We tried, foolishly, to use our own product to manage the software development process, and it was a disaster. Software and buildings might have some things in common if you really work the metaphor, but in the end treating software as software and construction as construction is the best way to go. Trying to shoehorn the assemblage of abstractions and code into the framework of physical construction, while it seemed like a good idea at the time, is a fool’s errand.
“In construction, plumbers don’t do electricity, electricians don’t do carpentry, and none of tradespeople do any top-level design. (The general contractor might, but not the individual plumber or electrician.)”
That is a lot less true than you might think, and the converse (specialization in software) also has some truth.
For example, electricians do in fact do a small amount of carpentry, and the design of the electrical system or plumbing system for a large construction project is significant.
On the other side, there are various specialities in software development – for example, Susan Kare was very much a part of the development of the original Macintosh operating system, even though her conrtibution was not mainly one of writing exectable code.
I think people who have only done one or the other of software/building construction have a some misconceptions about the other sides work.
I think my main argument is that the process of making things – anything – is very similar, regardless of the thing being made.
If people would look more for the similarities and defend the differences less, I think we would make better things.
I am very interested in the software Todd describes, that was created to manage construction projects – the reasons it didn’t work for managing software, if examined carefully, probably do yield an understanding of what some of the practical differences are – for example in the size of tasks to be assigned and tracked, and the costof change. But… I predict that these differences, while real and significant, are mostly differences of degree, not of kind.
I agree with Johanna, as I usually find myself doing. I do not think that creating software is analogous to building construction. Both utilize the “project” approach, or at least should use it. However, creating software has more in common with R&D projects in many aspects than it does with construction.
Because we use certain tools, mainly project management software, to assist us in managing our software development projects, much of the underlying assumptions, and also the terminology, of construction has been used on software projects. This does not necessarily make it apt, nor are these terms used in exactly the same way.
Two examples of construction management theory that do not translate well to software development, in my opinion, are critical path methodology and earned value management. Critical path is absolutely essential in construction planning and control. In software development, we are usually faced with critical resources, and the critical path is an illusion. However, critical path is absolutely essential to the functioning of the project management software.
Earned value management is very applicable to construction as it is evident that interim deliverables do indeed have real value. Many construction contracts rely on interim payments based on these deliverables. In software development, interim deliverables may have no value at all, especially if the project is changed, postponed or abandoned. The height of folly in project management is combining earned value management with percentage of completion. I will make an exception to this, as Johanna has pointed out elsewhere, in iterative development. Earned value can have “some” value, but only if the results of an iteration are actually implemented and used. However, there are better ways to assess iterative development.
Sorry, Matisse, but on the whole, I don’t like the metaphor either.
I’ve been collecting links on this topic for sometime. You can puruse them here: http://clabs.org/blogki/index.cgi?page=/ComputersAndTechnology/ConstructionAnalogy
Jürgen, thank you. Fixed. (I hate when that happens; I thought I’d check the link.)
The link to Matisse is broken. It has to be: http://twoalpha.blogspot.com/2006/04/software-development-is-like-building.html