Phew, August is finally over -- no, not 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 skyscrapper, well that's something you'd definitely going to leave to professionals and it requirers yet another set of tools, processes and professionals. Software doesn't work that way. 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 skyscrapper 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 from customer requirements (adding stuff, exchanging stuff) or because of the realities of the project (height and angle problems that were 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 who 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.

September 07, 2010
URL:http://www.drdobbs.com/architecture-and-design/so-do-we-build-software/228701156

Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.