Architecture is a Poor Metaphor for Software Design

I've recently been thinking quite hard about software architecture. Not just about UML diagrams and classical design patterns and other technical gubbins, but more and more about what it really means to be "doing" software architecture, and moreover to be doing it well.

And it seems to me that architecture is actually a very poor metaphor for software design, so this is an attempt to get my thoughts in order on that front.

Building Skyscrapers

We've all heard some version of this quote repeated by someone more senior than us at some point in our careers:

When you build a skyscraper, you don't start with a shed and keep bolting bits on until it's tall enough. It will collapse under its own weight! You need to build it on strong foundations, and plan every inch of it before you begin construction.

The quote is often accompanied by an assumption that the implications for the software development process are obvious and unquestionable.

It's a particularly insidious statement, in that you can't actually argue with it: it is true that you don't build a skyscraper that way. But we aren't building a skyscraper, we're building software.

Software isn't like bricks and mortar - or steel and glass. Software is soft. One of the most salient characteristics of well-designed, well-built software is that you can change it over time. You can, and - in order to continually meet the needs of the people who pay your salary - must. Given the right practices and processes, you can evolve a small web app (shed) into a huge distributed enterprise application (skyscraper) should the need arise.

Furthermore, in the same way that to a homeless man on a rainy day, a shed today is worth a lot more than a skyscraper in five years time, getting that web app live this month will be worth significantly more to your business than waiting a year for the enterprise app to arrive.

The priority is getting it out there. Bill de hÓra once wrote, entirely correctly:

Design the smallest system you can, help deliver it, and let it evolve toward the grand vision.

That doesn't sound much like building a skyscraper at all. Skyscrapers are irrelevant, and the metaphor is a poor one.

An Ongoing Responsibility

Another way in which software design is not like building design becomes apparent once the project is completed, and is released into active service. At this point the building architect's work is done; he or she moves on to the next project, head filled with dizzying thoughts of that next iconic office tower.

Yet for the software designer, one of the most important phases of the sofware development process actually begins here. As I previously mentioned, a real application must evolve. It must support the ever-changing demands being put upon it, be they commercial or technical.

The challenges here are nothing like architecture. The skills needed involve listening, observing and learning. Mistakes have to be acknowledged and rectified. Feedback from real-world use has to be collected and fed back into the design. How is it scaling? What features are users actually asking for now the software is in their hands?

There will constantly be a tweak here, a trim there, and the occasional complete change of plan. In that sense, software design can be more like gardening than architecture.

I'm not the first to raise the "gardening" metaphor: Andy Hunt and David Thomas raise it in their excellent, invaluable book "The Pragmatic Programmer", and I think it's fitting. Unlike a building untended by an architect software grows, seemingly of its own accord. Unless clear and constant design direction is maintained thousands of lines of poor code, complex dependencies and embedded assumptions will spring up, strangling a project and finally bringing it crashing to the ground. This is what actually kills real projects in the end. Software designers have to be ruthless with the weedkiller.

I doubt that the metaphor will catch on (one has to think of one's CV, after all), but the fact remains that to visualise software as an edifice - an immeuble - is unhelpful. Comparing software design to building design is misleading and harmful.