Software Isn't a House
I came across a discussion recently (I can't remember where) about how the typical comparison between writing software and building a house is flawed. The article was pretty compelling, pointing out that because a building is something very tangible and physical, it doesn't actually compare very well to software.
For instance, you can't refactor a building. Replacing the plumbing would be too costly. And yet, such activities are common place with software. It is here that the metaphor fails to capture the essence of software. And because of this failure, the metaphor perhaps puts a greater emphasis on upfront design than is truly needed.
Which is where I think agile software development practices come in. These practices favor the approach of designing as little as you have to and coding as soon as you can. When you come to a point where refactoring is needed, go ahead and do it. Constantly modify the code to make it better, but make it only as complicated as it needs to be. Could you imagine building a house this way? Getting halfway through pouring the foundation only to realize that there's a better way. It would be ludicrous for housing projects to proceed in this manner and yet the house metaphor is one of the most common techniques used to describe software development.
So what metaphor is more appropriate? Therein lies the problem. I haven't read of one and I haven't come up with one on my own. Hopefully, in the not so distant future, inspiration will strike. I'll be sure to write about it here when it does.
(3 votes, average: 2.00 out of 5)
Loading...
I think that a fitting metaphor would be that of organising a dinner.
Your objective is very clear - let's say, accommodate 6 guests and feed them, so they can have an enjoyable evening. You need resources (food + your hands), infrastructure (crockery, chairs, table, etc) and some planning to make sure you can satisfy the stakeholders.
You can spend months planning what to do, down to the most minute details, or you can just improvise with what you have in the kitchen. You can get your recipes ready before-hand and follow them to the letter, even though it might be the case that one of your guests turns out to be a vegetarian for which your steak pie would not do; or you can just ask them time after time "what would you like now"? Of course, these are the two extremes, but I think that most IT project management scenarios can be drawn as parallels to such an event.
And, as with software projects, once the dinner is consumed you can start preparing the next one :)
An architectural designer's comment regarding the house / software metaphor and refactoring:
The use of computers in the design of a building has significantly changed the building industry. Most projects today are fully conceptualized, analyzed and scrutinized during design development and are essentially "built" using highly advanced BIM software (AutoDesk REVIT) many times over prior to ground breaking. To use the metaphor that one can't simply pull the plumbing out of a building is, virtually, obsolete. Every linear dimension of copper is accounted for (scheduled), as are the quantities and product specifications of every air-trap, coupling and other random what not that may be used in a given project (accounting for which is really boring work, mind you).
Does this mean the software-development / house metaphor widely regarded as obsolete, is no longer obsolete? Is it now a double-negative and therefore suddenly current?
The house metaphor came to us from Waterfall Model kingdom. This was the time of technological challenges. Today is a time of business challenges and methodological challenges.
Nowadays there are number of approaches to build the software. For the sake of simplicity I would classify them as Classic and Agile. The most rigid of classic approaches is waterfall model, whose major assumption is that "what we know now is what we will develop".
This is where house paradigm comes from — ability to embrace the change is discouraged, ignored, and simply put "out of the law". When you build the house it is simply impossible. Another thing which house metaphor lacks is a feedback loop — you know the sequence of operations you need to do and at the end you get the building. In almost every book on project management building industry is mentioned as an industry with 99% predictable budget and schedule.
All my "maturity" in the industry I managed the development of the products and systems which are installed for 100 to 200 customers. They have versions and they are improving over the time. Single products grow to be complete product lines and cover neighboring areas.
I would compare development of software product with growing the garden — you start with the piece of solid ground. You even know to some extent what you want your garden to look like, but only to some intuitive level. Then you go and buy some seeds and some seedlings, based on your intuition and the picture of the garden you have. Then you plant your seeds and carefully monitor what happens. You nurture them, you grow them. Then you take ten steps back and you see what happens. Sometimes it is far away from what you planned. Then you take corrective actions — you weed away the plants which creates dissonance, change your initial plans, bring another plants and seedlings, those you never planed from the beginning. You nurture your plants, step back and take a look, ask your friends what they like and what they do not. And then iterate again and again.
Agree? Disagree?
I agree that the comparison of building a house to that of building software has many flaws. However, what I think the metaphor does capture is the importance of requirements analysis. Getting the requirements right for both building a house and building software is critical. Assuming that the role of a software developer also includes that of a software architect, in order to design a solution you need to know what "problem" you are trying to solve. A lot of emphasis is quite obviously placed on the design of a house with the role of the architect and the builder being clearly defined. This distinction of roles is also required when building software and to that end the metaphor work well.
Capturing the requirements of a house can be very difficult and a good architect is hard come by. In my opinion, a good architect is someone who can capture the requirements of the customer and advise the customer on the implications of their requirements - not all of their requirements may be technically sound or even feasible. The same holds true for a software architect. The software architect is faced with the added difficulty of some customers not being fully aware of their overall requirements, this is where agile software development practices can help. However, even with agile software development practices, the software developer/architect is working from a set of requirements (all be it only a subset of the overall requirements) and is aware the requirements may change.
The metaphor has flaws but taken at a high level works very well. When trying to describe what software development is to a lay person, the metaphor captures the essence of what it is without over complicating it. I also think seasoned software developers have a lot to learn from the metaphor - namely as a software developer you are generally answerable to a customer, you provide a service. Too many software developers provide solutions to what they think is the problem not to what the customer knows to be the problem