3 ms·

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

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’.

gnfargbl 3y ago
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?
- jameshart 3y ago
  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.
seadan83 3y ago
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! Really interesting metaphor!

gnfargbl 3y ago

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?

jameshart 3y ago
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.

seadan83 3y ago

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! Really interesting metaphor!