What can routers at Centre Pompidou teach us about software evolution

Back in June, I was in Paris for the NewCrafts conference to talk about the growing opacity of software systems. This was fun, partly because NewCrafts is a fantastic conference (you can already get your tickets for 2024!) and also partly because my talk (arguing against many established "good engineering" practices) was in many ways arguing for the exact opposite than one of the keynotes, leading to many interesting conversations.

While in Paris, I also visited the famous Centre Pompidou. Perhaps to the dismay of many modern art lovers, I spent a lot of time staring at the ceiling looking for routers.

Spot the routers at Centre Pompidou!

Routers at the Centre Pompidou

The iconic building is sometimes called "inside out" or "high-tech" building. It exposes the typically (more or less well) hidden infrastructure of the building, putting much of it on the exterior, and uses a colour coding to "enliven its facades and outline its structure" using:

• Blue for air flows (air-conditioning)
• Yellow for electricity
• Green for water circuits
• Red for pedestrian flow (escalators and lifts)

You can see all of these colours in the above photos and they definitely give the building its iconic look. But it is also clear that there are things that do not fit into the nice colour scheme designed when the building was built in the early 1970s. Routers are definitely one of those things!

Once you start looking, you will find quite a few routers in various random places in the building. They are typically somewhat near the yellow-coloured electricity racks. But they are in other places too. Sometimes, there is no electric rack nearby (and you need a lot of routers for a decent wifi) and sometimes the electric rack is behind something (like the green water pipe) and so you find routers sticking from the ceiling on various kinds of extensions, attached to green water pipes, blue air pipes or whatever else was available.

This is, of course, a beautiful metaphor for software construction. When we build software systems, we also understand the requirements at the time of construction, come up with a good way of structuring software and then build the system according to this structure. In software development, we now know that requirements change over time and we have development methodologies that make it possible to adapt systems. But, are we really refactoring systems in ways that are like adding a new colour to the Centre Pompidou building in order to reflect the need for a new kind of network? Or are we instead attaching routers to whatever pipe is available in the right location?

Modifying a physical building is certainly in some ways harder than modifying software system, so the metaphor is not perfect. You can do modifications while the existing version of the software system is being used without "closing it down for maintenance". Centre Pompidou itself will, in fact, close for renovations for 5 years. When it reopens in 2030, will there be a new colour for the internet? And how soon before a new kind of infrastructure will be needed?

If they asked me to build it...

How Buildings Learn by Stewart Brand

Software engineers are well known for giving advice about things we do not have a clue about, so here is my contribution! How should a building like Centre Pompidou should be built so that it does not end up with routers sticking out from the ceiling?

In How Buildings Learn (a book I already referenced in a blog post and a related paper), Stewart Brand looks at how buildings evolve after they are built. They need maintenance and (somewhat) continuous attention, but this is hard to teach:

Too often a new building is a teacher of bad maintenance habits. After the initial shakedown period, everything pretty much works, and the owner and inhabitants gratefully stop paying attention to the place. (...) It might be better if some of the original work were intentionally ephemeral, with everyone knowing it will require maintenance or replacement within a year.

Anyone who was a maintainer of a project based on the JavaScript ecosystem knows that this applies to software too. If you leave a project untouched for a couple of months and run npm update, you will probably have an unpleasant time. If you, instead, get into the habit of running npm update every month, you will probably be able to cope.

But can this idea be generalized to (building or software) construction? Imagine that you want to build the Centre Pompidou in a way that will make it possible to adapt it when it turns out that a new kind of infrastructure is needed. The way to do this may be to plan it so that you start with just some of the infrastructure, knowing in advance that you will need to add more soon. What if you build the building with just the yellow and green parts (electricity and water) and intentionally did not, in advance, plan the air flows and pedestrian flows? You would need to design the basic structure to be adaptable in a way that accommodates any possible design of the structures that you will need to add later.

I admit, this is probably not a way to build an iconic post-modern building, but can we learn from this idea to make building of software systems easier?

Is there a silver bullet?

No Silver Bullet (illustration) by Fred Brooks

In a joint presentation that I did recently with Joel Jakubovic at Mycroftfest, we were talking about Joel's research and also the guiding question of whether programming can be made easier. The talk will (hopefully) turn in the paper, but in the meantime, I will borrow one idea that is relevant to the routers at the ceiling of Centre Pompidou.

If we want to imagine a way of making software development easier, we face the challenge posed by Fred Brooks in his No Silver Bullet article:

There is no single development, in either technology or management technique, which by itself promises even one order-of-magnitude improvement within a decade in productivity, in reliability, in simplicity.

Brooks' claim is based on an insightful analysis. He distinguishes between essential complexity, which is the complexity resulting from the inherent difficulty of the real world problem and accidental complexity, which results from our imperfect tools. We can reduce the accidental complexity (by building better tools), but the essential complexity will remain. But unless the ratio between accidental and essential is more than 10:1, reducing the accidental complexity (even to 0) will not yield an order of magnitude improvement.

There is no way of avoiding the essential complexity in big and complex software systems. But what if there is? In the talk with Joel, we suggest that perhaps software could be build by a sequence of gradual adaptations, starting from a simple initial system. Arguably, this is how software systems today often evolve anyway. You start with something that is relatively simple and gradually add features to it over time. (In other words, you do not typically plan a software release on a CD a couple of years in advance these days!)

If we take the idea of gradual adaptations seriously, we can avoid the Brooks' challenge. But one important part of the solution is that we should not need to fully understand the entirety of the software system we are modifying each time we are making a change. In other words, if we build a Centre Pompidou skeleton with just electricity and water, we should not need to worry about how those structures work when we are adding other aspects later. (The problem is that the structures interact, so they need to be built in a flexible enough way - and likely expensive and wasteful way - to accommodate all possible interactions that may be needed later.)

But if we can build software in a way where we start with initial scaffolding and then gradually add structures to it with the help of new kinds of tools that help us understand where they may fit, we could perhaps spread out the (inevitable) essential complexity over time and make software construction, in the long term, an order of magnitude easier.

In lieu of conclusions

The routers sticking from the ceiling at Centre Pompidou are a symptom of little flexibility and too much up-front design that naively thinks we can understand the problem well enough to make unchangeable structural decisions. In principle, software should be more adaptable, but it typically is not. Any large software system will have "patches, ad hoc constructions, band-aids and tourniquets, bells and whistles, glue, spit and polish" (to quote De Millo, Lipton and Perlis) that were not intended in the original clean design.

How can we avoid this? What would be the software equivalent of building just the "yellow and green" structures of Centre Pompidou, so that adding the "blue and red" structures teaches us how to add more structures in case we need "purple" for the wifi? Late binding as envisioned in languages like Smalltalk (and the follow-up research project, including Joel's favourite Open, extensible object models) is one part of the answer. But I think we also need different way of thinking about programming. We need architectures that are designed for adaptation. And perhaps, we also need to build software in a less optimized and more wasteful way, because that is the only way of making sure that future adaptations and additions will be possible in a way unconstrained by earlier design decisions.