When explaining our software development process to clients, the Lab3 team often finds itself comparing developing software to the building of a house. On the face of it, there are a lot of similarities between the two. Making last minute ‘minor’ changes to functionality is a lot harder than if it was planned, for example (like changing a room to be a bathroom will involve much more expensive plumbing than if it was always the plan). Does the model always apply, though? I analysed our recent projects to find out.
The Metaphor in Practice
Most people understand that changing things that have already been made is difficult. It’s easy for most people to understand the physical world; when your builder tells you that it’s not going to to be easy to put a different shaped window in the hole he’s already cut, it’s not hard to see why. Software is, however, far more intangible. Swapping a piece of functionality for something similar can be as complicated as switching window sizes. On the other hand, in some cases it can be super easy — and this is the problem. To everybody who doesn’t understand how a particular program was implemented, the rules for when something will be expensive and when something will be cheap are very unclear — even to other developers.
The cost benefits of planning ahead are also similar. Adding a new room to your build at a late stage might bring a whole range of problems. Your foundations might not support it, and the hours spent on the section of wall you’re removing will go to waste. In the same way, software projects are designed — ‘architected’ — with a final product in mind. The technologies chosen and the structure used all might make sense for a given solution, but could be inefficient and wasteful as the project changes.
Maintenance is another area where house and software are similar. We all want things to be ‘solid as houses’, but if you think about it — houses do take a lot of maintenance. Just like wear and tear causes houses to be bit-by-bit replaced over time, software will never keep working as it may once have. Everything moves on without it — underlying platforms change or security vulnerabilities are found in other software you depend on.
Why It Doesn’t Always Apply
Our ‘house building‘ metaphor isn’t perfect though; in some ways, software is very different. For one thing — it’s not constrained by the same physical laws. Building a four bedroom house on the footprint of a motorhome is physically impossible. We can still make the software equivalent, it just probably isn’t a very good idea.
Another thing that adds to the flexibility of software development is in the way ‘construction’ takes place. Our team, as is quite common in the industry, uses ‘Agile’ development methods. This means that we build things room by room, and that at every stage there is a usable ‘house’ — even if it’s just a standalone kitchen. Compare this to your average house build; the frame goes up first, followed by roof, cladding, and windows — the house is built as one item. When building a house, changing anything means working within the confines of what you have already established, and you only get the value at the very end.
The needs of the client are very different, too. During the course of a building project, it’s unlikely the needs of the client will change. If they do, it’ll be minor — maybe they need four bedrooms now, not three. Software projects are often so exploratory, that the original requirements might be completely useless within the first few weeks of development. We try our best to fix these requirements in place before a project starts, but sometimes we do need to make changes to align with the business case.
It’s clear that while it is a useful model for explaining how some parts of software development work, the ‘house building’ analogy is far from perfect. When it comes down to it, though, you can improve a software build with good planning and management in all the same ways that you can improve the process of building a house.
