Housebuilding

We all know the analogy - developing software is like building a house. This patronising explanation typically followed immediately by the follow-up that we need to get the foundations right before we start building any of the walls, let alone start plastering, wiring or putting the roof on.

But just how valid is this comparison and does this help or hinder? One would suspect the former, and it would seem reasonable, given the obvious pitfalls of not thinking through the solution in its entirety before cutting code. I mean; consider the effort required to convert a large system between .Net and Java if you discovered that you needed the portability that the JRE offers? Or the sheer hassle in migrating from Access to Oracle because you thought it was a 2-user system and it turned out to be 1000-user?

Clearly there needs to be some forethought, but is it really comparable to getting to the roof trusses and realising that your foundations weren't deep enough? Or that your 4 bedrooms don't fit onto the 2-bedroom foundations that you've laid? In both these cases you'd effectively have to go back to scratch and start again. But converting from Access to Oracle? Well certainly it's a lot of work, but if you've architected the system properly - separation of concerns, etc. then why would you need to change your GUI code? Or the logic you've coded in the middle tier to assess claims, or the link to the third party system for payment processing?

Ok, so perhaps not quite the same thing, but still - something that we should avoid? Fools rush in/etc.

But there is more that the analogy doesn't consider. And these things are significant - how about continuous integration? How does that fit with housebuilding? Or the agile concept of features and 'done', or test driven development? These are all development techniques that seek to test as much as possible as early as possible, identify defects as soon as they are introduced and improve estimation. We all know these are sensible but how does this correlate to housebuilding? Perhaps we should be recommending that a building builds all the way to the roof in one thin turret so that we can 'test' that the roof is watertight (an 'habitable room' feature)? Or that he builds scaffolding to the exact size and shape before laying bricks (TDD)?

It doesn't make sense. And these are good examples of why development - even green field in this case - is fundamentally different from house building. When you start to look at brown field the comparison is even less valid.

So we're going to build an extension every month. When is the last time you asked a builder to do that? Ok, you might argue that some product evolution is more like wallpapering every so often, or re-painting the skirting boards. But that isn't my experience and I'd attribute this pattern more to legacy, regulatory-driven or end-user customised COTS packages. For line of business applications challenged with keeping up with the business or commercial offerings keeping pace with competition, there's a significant amount of change and IT have to be able to accommodate this change regardless of the 'structural' impact to the system.

So one week it might be some wallpapering, but more than likely it's converting the single garage to a double, adding toilets, enlarging rooms, etc. And then there is the case of the upgrade to particular components - I'm not sure the last time Ikea released a v2.0 of their 'kitchen' and forced everyone to upgrade, but that's what happens ..

So the more I consider the analagy the more I think we need to take it with a pinch of salt. And any decisions based fundamentally upon it should be very carefully considered.