So do we “build” software?
So do we “build” software?
Join the DZone community and get the full member experience.Join For Free
Whatever new awaits you, begin it here. In an entirely reimagined Jira.
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?
Published at DZone with permission of Arnon Rotem-gal-oz , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.