Software Development Analogy

There has been much debate of a simple analogy; that building software is like building a house and that software development is like construction. Having read and considered the all arguments surrounding the software construction analogy and given that both camps have appeared to rest their cases, it was appear to be an opportune time to reach some kind of determination on the matter.

In commencing, we need to recognize the contribution made to this debate, each party drawing upon their clearly extensive experience in the area. Both Glen Alleman (Software Development is similar to Construction) and David Anderson (Construction is nothing like software development) have put forward some interesting points.

Not least of which both parties are searching for an analogy, which in itself is very enlightening. Clearly this is complex area hence the need for an analogy (I think this was the frist use of the analogy)to explain to those who may not have had firsthand experience of software development, be it a simple systems built by the collaboration of a few or complex systems built build by the determination of hundreds.

The pro construction analogy camp has delivered some very good insights, namely that the design changes during construction, leading to a disparity in “As Designed” and “As Built”. This being the case there is clearly collaboration and client interaction at play in the construction game.

Like construction change and client interaction are prevalent in software development, resulting in what can be a disparity between “As Designed/Specified” and “As Delivered”.

The against construction analogy camp has highlighted the issue of iterations, which unfortunately both parties have managed to pervert to some degree. Using the example of delivering only a working toilet in the first iteration does not fairly highlight iteration in the construction game. Similarly, the pro camps have not done themselves any favour by not elaborating or responding to this point. Not to do their jobs for them, much could have been made of the fact in construction there are often things that either near completion or completed, then they are required by the client to be change or ‘extended’, clearly this is a form of iteration. It is designed, built, looked at by the client, redesigned to improve upon it and then it extended or rebuilt. In these ways, it is clear that construction and software development share some similarities.

At this point the similarities end, construction is a physical pursuit and has its unique set of constraints whereas software is an intellectual pursuit having its own set of unique constraints different to those of construction.

I am sure that both camps would agree that there is adequate degree of complexity in software development and that the amount of capital invested in it annually justifies a description of it, which is not as over simplified as that of constructing a building. That is not to cast doubt of the complexity of construction but I hazard to guess that construction is better understood then software development.

A more fitting analogy of software development would probably be along the lines of a cooperative game subject to the constraints of game theory, which unfortunately is less understood then construction and software development combined.

Not to steal the thunder of an argument comparing software development to a game, refer to the presentation given by Alistair Cockburn at the 1999 ObjectActive Conference. Possibly dated by now but does highlight some unique point’s particular to software development.

The above work was also recently rediscovered by Jeff Atwood and has created equal amounts of debate.

So I hopefully I have put to bed the construction analogy, yet I fear I might of just of opened another can of worms in the process.