I love this metaphor - but I honestly don’t share the author’s optimistic take on the lesson for software architecture here. The Pompidou Center laid down clear patterns for how infrastructure should be handled - pick a color, make it visible, exploit the aesthetic qualities of the infrastructure itself as an architectural element. The philosophy is widely written about and studied.
But the maintainers who went in to install the WiFi network ignored all that and just did it a totally different way, following patterns established in other systems. They probably didn’t even consider that what they were doing was adding another infrastructure layer - at the time it was just a little maintenance project.
So the lesson for me isn’t ’how can we build systems so that the pathways to add new layers are clearly laid out for others to follow later’. It’s ’even if you lay out a clear pattern and paint it bright colors and signpost it and write extensive documentation about your design philosophy, maintainers will still come along and ignore it all and do it however they’re most comfortable’.
The metaphor extends to cover your point! I doubt that the wifi installers were unaware of the existing design patterns, since the language is pretty clear. I think it more likely that they were working to a budget and a timescale, which led them to prioritize functionality and expediency over maintaining the purity and clarity of the design. And isn't that like so much software maintenance?
And actually even more: the Wi Fi installers maybe even thought they were being respectful of the original design by installing unobtrusively. They didn’t feel like they had the authority to introduce a whole new infrastructure paradigm. They saw the people who went before them as having laid down an inviolable framework rather than a pattern for them to follow.
And damn it if that doesn’t describe the problem with so much legacy software development. Maintainers need to realize that they have just as much right to leave their mark on the code as the original authors. You don’t need to be unobtrusive and tiptoe around.
It’s often the lack of ambition in software maintenance that dooms the system ultimately to become a legacy burden and ultimately get torn down and replaced.
It is an interesting metaphor. To what extent is it the original architect's job to show or highlight these pathways rather than the maintainer?
I think the routers might be symptomatic of a lot of maintenance.
(A) maintainers are incentivized to graft fixes and additions rather than to find the way. They are not being payed enough to be able to care. They have a job, deploy a wifi mesh, so they use the way they know how because it is cheaper and easier to do something rote rather than integrate to the whole. This is the equivalent of throwing in a bunch of if statements and then walking away.
(B) rejection of the previous designers, "my way is better than what these dinosaurs hacked together - the technical debt in this system is bad and nobody knew what they were doing."
Thus is to say, I've been more intentional of late to wonder, "what types if things were the previous developers trying to make easy? Which paths did they lay out?" Even a system laden with debt, there might be patterns that are easy to continue. Same thing in the building, instead of mounting wifi as they had in other buildings, the routers could have been painted yellow and then hanging from the ceiling, perhaps mounted at head height. Which is to say, instead of respecting the art, the design, and doing something cohesive that could have been easier; instead routers (eg: springboot, orm, a new feature) were just bolted on without any thought, bolted on just as you would attach something in an assembly without care that this widget is different from another.
In sum, I see these two behaviors quite a bit. (1) this charging forward with a rote way to do something, to cheap and too hurried to understand context, to do any design, just bolt the thing on and move on. (2) no care, time, or respect to understand the existing design to know what has been made easy. Rather than sus out what us easy to do, the maintainer declares all previous developers idiors and all existing patterns and designs to be wrong. From this perspective, the new way is the only true way, even if what you are trying to do is actually something a previous developer did make easy (and following the existing pattern would indeed be easy, but nope, we need to out a feature flag in and build a new feature microservices integration, because "not built here" syndrome is strong) The thinking is hubris, the existing design is wrong, so everything is wrong and "your modern ways are the only thing that can fix it" - don't use any golden path because they are all wrong; eg: a building should be right side in! These routers should be tucked away! The building is wrong!
I know that this is not the author's point, and that it even undercuts his point, but it feels to me like the original color scheme was flexible to handle this development, it's just that people were not dedicated enough to it to put the work/money in to keeping it up. Which seems like a shame for a place like Centre Pompidou.
It's not hard to get an AP that supports multiple external antennas (this is quite a common feature of high end infrastructure-type wifi systems), hide it away somewhere with the antennas located appropriately and then just hit the antenna casings with a colour-matched spray can. Alternatively you could just spray the entire router cases, the chances of enough paint making it inside to interrupt anything is minimal.
Great article! Just a side note: those are APs not routers. Usually, routers are in a cabinet in this kind of installations. APs are the ones who handle the WiFi Connection, but are "similar" to a switch.
It seems evident that the wifi installers didn't "get the memo" about services using a uniform color - but then again, who knows if such a directive applied to wifi infrastructure would have existed. We might see all these APs and Ethernet runs as clear evidence of a new category of infrastructure in the building, and thus deserving of a new color, but others might simply see it as another piece of electrical gear, and yet others might not care at all. Without a control mechanism like a Benevolent Dictator or a pre-agreed standard, it's open season.
You also have the opposite problem of proliferation. Suppose you mandated Ethernet = white, what do you do when you introduce wifi? create a new color? overload Ethernet? what if you introduce private LTE/5G? is that also white? So you start to get into questions of types, and conversions between types, and again, without a control mechanism to think about these things ahead of time, you have a mess.
If Pompidou was still alive, he'd flatten the whole thing to build a new motorway intersection. A few ugly routers which don't integrate in their environment are a perfect fit for a building that bears that name.
But the maintainers who went in to install the WiFi network ignored all that and just did it a totally different way, following patterns established in other systems. They probably didn’t even consider that what they were doing was adding another infrastructure layer - at the time it was just a little maintenance project.
So the lesson for me isn’t ’how can we build systems so that the pathways to add new layers are clearly laid out for others to follow later’. It’s ’even if you lay out a clear pattern and paint it bright colors and signpost it and write extensive documentation about your design philosophy, maintainers will still come along and ignore it all and do it however they’re most comfortable’.