Refactoring a House: Software Architecture is Architecture After All

Now and then, fierce debates ignite on Twitter about whether the term Software Architecture is misleading or even harmful. The argument goes as follows: Code is ever evolving while buildings are static. Furthermore, making changes to code is easy and cheap and making changes to buildings is borderline impossible. Therefore rigorous planning of an architect is justified when building a house but a waste of time when writing code.

I always felt that this way of thinking is flawed. And when I recently did some work to prepare for the renovation of a balcony, it became clear to me that Software Architecture and real Architecture are very much alike. So let’s dissect the arguments and look at the glaring similarities.

First misconception: changing software is cheap

The notion that making changes to a big software project is cheap is utterly flawed. At least it’s not reflected in my reality. Sure, renaming a variable or function here and there really is not very expensive. But the same goes for replacing a carpet in your house. On the other hand, making a significant change to a particular feature that requires the combined effort of three programmers, one designer, and a project owner, is a different (user) story.

I assume people think making adaptions to software is cheap because most of us never had to foot the bill for a five-person development team. While many people can estimate roughly how much it costs to do some (in our view) minor renovations. Also, spending 1.000 € me money feels a lot more expensive than spending 1.000 € company money.

Of course, some things are easier to change than others. But again, I think the software <-> building analogy reflects that. Some things are swift and inexpensive, like moving stuff around (some lines of code <-> furniture). Other things are a little harder yet doable. Replacing parts of the construction (dependencies <-> parquet floor) for example. And some things are very, very expensive or impossible to do without a complete rebuild. E.g., swapping the framework (the analogy is just right there).

Second misconception: buildings are static

Again, I have no idea where this is coming from. I can only speculate that maybe it has something to do with the reality many US thought leaders live in. After all, there are very few old houses in the US. And selling your home and moving when circumstances change is more common. In most other parts of the world, plenty of buildings are a couple of hundred years old and went through significant changes as time passed. For example, my sister lives in a ~500-year-old farmer’s house that once was a mill. It looks nothing like a mill anymore, and it has central heating and running water nowadays.

I myself own a 40-year-old house where the ground floor was once more like a magazine but now is fully equipped to live in. Throughout my childhood, I first lived in a single room with my two sisters and later got a room that once was the dining room. The living room became the new dining room, and when I moved downstairs, the living room and dining room were converted back to their original forms.

And this week, I started to refactor the balcony. It took me ~8 hours to do some preparations. And it will take a team of three professionals two days to finish the work. I won’t go as far as to say that this will be cheap. But it is not as expensive as a development team of five making some significant changes to a particular feature of a large piece of software.

Me refactoring a balcony

Planning for change

Over time, the requirements imposed on the software we develop change. But the same is true for most of the buildings we construct. Does this mean we should not make an elaborate plan before building a house? Of course not! Although we’ve seen that buildings are far from static, we can all agree that not making a plan at all would be pretty stupid.

The same goes for software projects. So, yes, change is inevitable. But the answer can’t be chaos.

The question is not if we should make a plan before starting a software or construction project (or any project, really) but how and what we plan for. I would even go as far as to say having a good plan is even more important, knowing that things will change over time.

Big up-front design is dumb. No up-front design is dumber!

Planning for change is vital. And that, ladies, gentlemen, and non-binary people, is the secret of good (Software) Architecture. But don’t confuse planning for change with predicting the future. It has nothing to do with predicting anything. That change is inevitable is a given. And the same is true for the fact that we don’t know what form and shape the changes necessary will have.

When writing code, and especially when starting a new project, we should always keep in mind that we almost certainly have to touch it again at some point in time. Of course, some parts of our code will change more frequently than others. But as long as our codebase is healthy, we will touch almost all the code regularly.

Wrapping it up

I think one reason this analogy has such a bad reputation is that we often focus too much on planning for change in areas where not much change is happening, like adding multiple layers of abstraction to hide the fact that we’re using a particular database. Yet when we need to make significant changes to an existing feature, we’re not prepared.

We don’t only have to consider the technical aspects of our projects. But even more so, we have to plan for change at the feature level.

We can’t predict the future, but we don’t have to: change is inevitable. Plan for change!