So do we “build” software?

Phew, August is finally over – no, no, because we closed XSights, not even because my wife and I had to entertain three kids on vacation – the renovation of our balcony and living room made it a living hell. Oh well, at least it is over, and it got me thinking (at least when they weren’t banging, breaking, or otherwise making noise in general).

There’s this analogy that you  “build software,” and that is similar to  “building houses” – this is especially popular with software architects trying to understand what exactly they need to do :).

The analogies usually have something to them, but they only take you that far. For example  (which I have to admit I also used in the past) for an analogy:  if you are going to build a dog house, then you need certain tools and skills (and most of us can pull it off); if you are going to build a house, you might be able to design some of it, but you’d need help with most of the design, and way more tools, flows, practices and help with the construction. If you want to build a skyscraper, that’s something you’d leave to professionals, and it requires yet another set of tools, processes, and professionals.

Well, software that doesn’t work that way exactly. Sure, a hobbyist may use other tools than the professional (even that’s not always true), but with software, you might set out to build a sky-scrapper but start with a dog-house, then send into production a “dog-scrapper” and maybe one day end with a sports-arena because that is what the customer actually needed. You can’t do that with buildings.

An analogy I still like is that of building a new intersection in regard to introducing an architectural change (e.g., moving an enterprise to SOA) – with the idea that the business would not stop and wait until you’d finish your change and you have to build detours, only close some lanes, etc – just keep the business and information flowing.  Like the other analogy, though, it is still limited in its applicability.

This month, however, proved there are some similarities I didn’t think about:

• It turns out a building project can take twice as long as planned – why? Because the contractor took too much work and had his task switching a lot (half a day here, half a day there)
• It turns out that even though there’s a detailed plan, new requirements can still come up as the project progresses – both from customer requirements (adding stuff, exchanging stuff) or because of the realities of the project (height and angle problems that we’re not foreseen)
• It turns out that people can cut corners only to find out it would only get them that far (and  then have to re-do everything properly)
• It turns out teams matter – two neighbors are completely renovating. One is two months overdue, vs. the other team took a week to do what the other team needed a month to complete.

Oh well, while  I still think software is closer to writing a story than it is to building a house, maybe there’s merit in the building analogy after all… what do you think?