Agile Zone is brought to you in partnership with:

Arnon Rotem-Gal-Oz is the director of technology research for Amdocs. Arnon has more than 20 years of experience developing, managing and architecting large distributed systems using varied platforms and technologies. Arnon is the author of SOA Patterns from Manning publications. Arnon is a DZone MVB and is not an employee of DZone and has posted 68 posts at DZone. You can read more from them at their website. View Full User Profile

So do we “build” software?

09.21.2010
| 2001 views |
  • submit to reddit

phew, August is finally over – no, no because we closed xsights, not even because my wife and I had to entertain 3 kids on vacation – it was the renovation of our balcony and living room that 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 architect trying to understand what it is exactly then 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 use 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 sky scrapper, well that’s something you’d definitely going to leave to professionals and it requirers yet another set of tools, processes and professionals.

Well in software that doesn’t work that way exactly sure an 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 it’s applicability

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

  • it turns out a building project can take twice as longer than planned – why ? because the contractor took too much work and had his worked 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 form 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 matters – we have two neighbors  which are completely renovating  one is 2 months overdue vs. the other team that 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 then it is for building a house, maybe there’s merit in the building analogy after all… what do you think?

References
Published at DZone with permission of Arnon Rotem-gal-oz, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)