Bob: We’ve nearly finished Farmer Giles’ new house Wendy.
Wendy: That’s why I’m here; Farmer Giles gave me a message for you.
Bob: Yes …
Wendy: He’s decided that he’d like an extra bathroom upstairs.
Bob: But we’ve nearly finished!
Wendy: And he doesn’t like the colour, can you change it from wood to brick please.
Bob: [apoplectic] Why didn’t he tell us when we started?
Wendy: Calm thy apoplexy, lad – you’ll bust a blood vessel like that and end up ska’d for life.
Bob: Ah, pop humour, very good, but it won’t help with these changes.
Wendy: What’s the problem?
Bob: We can change the function of an upstairs room easily enough, but … We’ve invested too much time and effort in the infrastructure already. If we add the new bathroom we’ll have to redo most of it.
Wendy: He’s broke his leg; he really needs the bathroom upstairs.
Wendy: Why is it such a biggy?
Bob: It’s not; it’s just that if we’d known before we started we could have saved time and money designing it the way he really needed it, and we wouldn’t have to rework a large portion of the building.
Wendy: But Bob, you know that people change their mind all the time, why didn’t you build it so that it could be easily changed?
Bob: Because this is a building, it’s hard.
Wendy: My uncle Bryan builds software, and he says that by delaying decisions as long as possible and implementing things at the last minute, he minimises rework. He also says that by building things with no duplication, change only ever effects a single location, and so has a lower impact. I think he calls it "Agility".
Bob: Yes, but this is a house, it’s not like software – it’s hard. For example, farmer Giles wants this house in brick, not wood. We can’t change the construction that radically this late in the project, so we’ll have to paint it – it’ll take days. The same change in software would take a few seconds, and so would the addition of a new bathroom – a new instance of the bathroom object, and it’s done.
Wendy: Farmer Giles told me something else too.
Bob: Oh no, what is it now?
Wendy: His wife has just bought a new combine harvester, and wants an adjoining garage built for it – says it has to be fully integrated.
Bob: I don’t care – they bought it, then can deal with it – it’s their problem not ours.
Wendy: But Bob, you’re the builder, you can fix anything.
Bob: Anything except the users’ requirements, Wendy.
Bill Ross recently expounded the idea that software architecture is similar to building architecture. There are many differences, perhaps the most important of which is that we are a lot more flexible in the face of change than a typical building architect.
Another difference is that a building architect rarely has to combat customers who constantly change their minds. A building architect is looking at a static building that will survive 50 years or more (or possibly hundreds). We develop software to last a couple of years – at the most.
If one spends time designing and building architecture up front there is considerable inertia once the project is under way. There is a tendency not to want to change things, no matter how good the business reason for the change. There is also a cost associated with every change, for rework, and for wasted work. Notice how Bob the Builder wouldn’t do the integration work with the new system, throwing it back in the customer’s face. This is bad for your business.
While it’s possible to follow the process used by a building architect to produce software it’s not the only process, and it’s certainly not the best process.
And don't forget the Software Development Conference, kicking off in Wellington on March 10. There are lots of great speakers this year, but it came to mind now because my old mate Scott Ambler will be there, one of the thought leaders of the agile modelling school.