The construction analogy

I did it again - just like so many others before me.

Last night, Rob Conery dropped a rant about an industry heavyweight who, Rob felt, was doing us all a giant disservice by suggesting that perhaps less could be more, process-wise.  So, of course, I chimed in, and I used the tired, old construction analogy -- you know -- building software is like constructing a house, right?

In my defense, the specific point I was trying to make was that the software industry isn't mature in the same way as construction.  Where you have building codes in Civil Engineering, for instance, there's no equivalent binding set of rules governing how software is built -- just a nebulous collection of "best practices".

Then, this morning, I read another post on the IxDA discussion board trying to explain how software design (specifically, functional specifications) is like the function an architect performs when someone builds a home.

Clearly, there are holes in that analogy, and I pointed out a couple in a comment on that site.  The complexity (in terms of options) in construction pales next to software development in all but trivial applications.  As I mentioned, in my comment, a buyer could sit with an architect and describe parts of a home in pretty general terms, and be quite satisfied with the resulting home, because there already exists a rich vocabulary of assumptions about how homes are supposed to work.

Software interface design is automatically more complicated than physical buildings in part because we’re emulating “real” things in software.  All the metaphors and affordances we design into our software provide unlimited complexity, such that any conversation about what a customer wants to see in software has to occur at a high level of detail.

Beyond specifying behavior, the process of construction proceeds quite differently in software, as well.  When building a home, you quickly come to understand that some aspects of construction are literally “set in stone” very early in the project, and more importantly, these things are intuitively understood by the customer.  If a homeowner wishes to change a foundation or the frame of a home, he’s not surprised to learn that this will be an expensive change; anyone can see how one is built upon another.

Building codes also help constrain choices (and therefore, costs) when building a home.  There’s simply no arguing about how studs are spaced, or the materials that are used for different parts of the home, because these are mandated by building codes.  In software, everything is negotiable, which implies that it must be specified.  Once again, the analogy breaks down.

As many times as I’ve seen the construction analogy, it’s clear that a lot of people want it to work.  Just remember that it only works to a point.