Stewart Brand’s “How Buildings Learn”–3 lessons for Software Architects

There is a reason why there is a specific position in software engineering called Software Architect, and, if you ask 10 different people what software architecture is, you’ll have 10 different answers.

On the other hand, if you ask 10 different people what an Architect is, most of them would say that they are responsible for designing houses, factories, office buildings, and other structures. Architects spend much of their time in offices, where they develop plans, meet with clients, and consult with engineers and other architects.

This is the same job that a Software Architect does, but instead of creating houses, factories, and office buildings, they create the most complex systems that are currently allowing millions of people to browse their favorite applications: Video Streaming Platforms, Social Media, Food Delivery, Instant Messaging apps, etc.

If you want to know how to be a good software architect or how to be a software architect, you can find a lot of help in diving deeper into the similarities between traditional buildings and software architecture based on some of my favorite quotes from Stewart Brand’s How Buildings Learn, written in 1994. How buildings evolve is a perfect analogy for designing systems!

Lesson #1: Temporary is permanent, and permanent is temporary. 

As soon as we start writing our first piece of code, we are writing the foundations of our system. Likewise to building foundations, if they are not well thought out, designed, and implemented, everything will fall apart within time. We must carefully create software that allows itself to survive in the future to the latest state of the art. Stewart Brand’s How Buildings Learn reads:

Cars came, grew in size and number, then shrank in size, and garages and car parks tried to keep pace.

Once there was a world where people only traveled by train, then horses with carriages, and then cars. The families that transitioned from horses to cars, had barns initially, and their house was built with the idea that they would always have space for carriages. The transition took around 50 years, and people had to adapt to the “new” standard.

Most of the people didn’t have the space for a whole garage in their house, so the car stayed out of the property, in the streets, when not used. Of course, this is not the ideal place for a car, since rain, wind, dirt and other factors would cause damage to it, and they were quite pricey.

They had to build a garage. And most of the time, there was no place for it. So they had to rebuild the entire house or move to another place.

In software, it is quite common to have an established piece of software that once was thought that it was going to be there forever, but you’ll always hear software engineers talk about how necessary a refactor of the system is needed to be able to add a new unexpected feature to it.

Contrary to the thought that everything that you build will be permanent, we can also have pieces of software that are temporary and serve the purpose for developers to play, create, research, implement proof of concepts, and then discard them right away. These projects move on soon enough, but they are immediately supplanted by other temporary projects of which it turns out there is an endless supply.

But wait! Although these projects are temporary, the space for them is reused in different fashions. For this example, we can use Building 20 from the Massachusetts Institute of Technology:

“Although Building 20 was built with the intention to tear it down after the end of WW2 it has remained these thirty five years providing a special function and acquiring its own history and anecdotes.”

Building 20 is famous for its longevity without anyone wanting to demolish it. It served as a “magical incubator” for many small MIT programs, research, and student activities for a half-century. 

Due to Building 20’s origins as a temporary structure, researchers and other occupants felt free to modify their environment at will. As described by MIT professor Paul Penfield, “Its ‘temporary nature’ permitted its occupants to abuse it in ways that would not be tolerated in a permanent building. If you wanted to run a wire from one lab to another, you didn’t ask anybody’s permission — you just got out a screwdriver and poked a hole through the wall.”

I’m fairly certain that you can relate this to countless MVPs that you created during your career.

Lesson #2: Dealing with the past

“The complaints and jokes never change. When we deal with buildings we deal with decisions taken long ago for remote reasons. We argue with anonymous predecessors and lose. The best we can hope for is compromise with the fait accomplish of the building”

All developers would be millionaires if they got a nickel every time they say “Who implemented this and why does it work like this”. Many times, systems are restricted from implementing new features because it deals with bad design decisions from the past—no one can know the future, and planning for it is sometimes a bad idea–-so developers have to deal with these issues all day, and they rapidly grow bored, frustrated, or embarrassed by what they see. Between constant tinkering and wholesale renovation, few systems stay the same for even ten years.

“What does it take to build something so that it is really easy to make comfortable little modifications in a way that once you’ve made them, they feel integral with the nature and structure of what is already there?”

How do we ensure that we are going to be able to support new features, support the old ones, and plan for the future? I don’t have the exact answer, but one thing that worked for me is to follow the KISS principle (Keep it simple, Stupid!). 

It’s simply wrong to try to predict the future, that’s one of the few things that humans haven’t mastered yet. So when you work on new features for your system, please keep in mind that they are going to be rewritten, refactored, tested and will not be the same in a couple of years. To avoid pain from your future fellow developers, please keep it simple.

In regards to refactoring, it is not rare to be seen as a waste of time for engineers, but as you would in your house, you have to look over to see the current state of it. Think of refactoring as having a plumber or an electrician coming to your house every one or two years to oversee that everything is still working properly. There are times where the refactor – the solution of technical debt – is minimal, order the cables, change a bulb, etc, but there are times where a major refactor is needed—pipes break from extensive usage, they get clogged, loose outlets, you get it—and this cannot be avoided.

Lesson #3: Maintenance of Buildings

In regards to refactoring, it’s not rare to be seen as a waste of time for engineers, but as you would in your house, you have to look over to see the current state of it. Think of refactoring as having a plumber or an electrician coming to your house every one or two years to oversee that everything is still working properly. 

There are times when the refactor – the solution to technical debt – is minimal, order the cables, change a bulb, etc, but there are times when a major refactor is needed—pipes break from extensive usage, they get clogged, loose outlets, you get it—and this cannot be avoided.

There are several challenges with software maintenance. The same could be said for buildings.

Maintaining a house that is one year old is not the same as maintaining an 80 year-old one, or even older. Things that support the house are much more fragile as they age, and maintenance is more needed. One could say that it requires an architect, plumber, and electrician that is experienced in these types of buildings.

The same concepts apply to software. A software that has just been released needs completely different maintenance than a software that has been supporting banks for 30 years. The technologies used have changed radically over the years, and the system needs an expert in those languages and tools. 

As we have seen before, also refactoring gets much harder when the software is really old, and it would require many tests to ensure that all of the functionality keeps working the same with the changes or refactors that we do.

It’s fair to think that one would be much better if one would start from scratch again. But that’s not always the possibility. The same happens to buildings—one cannot simply demolish a hospital even if its infrastructure is really old—but what is possible is to expand it, make it more modern, and improve its current capabilities.

How Buildings Learn

Over this article we have discussed the similarities between Software and Buildings. We’ve learned how they can be compared and contrasted, and what we can learn from them. 

My gratitude goes to Steward Brand, who wrote this excellent book that inspired me to write this post.

Next time that you are going to add, expand, delete or change your system, think how long that will be there—the foundations of your own house.