[HN Gopher] Routers at Centre Pompidou and software evolution
___________________________________________________________________
Routers at Centre Pompidou and software evolution
Author : mohsi
Score : 37 points
Date : 2023-12-08 04:16 UTC (2 days ago)
(HTM) web link (tomasp.net)
(TXT) w3m dump (tomasp.net)
| evilmonkey19 wrote:
| 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.
| jameshart wrote:
| True, but that's also kind of the point - in the Pompidou
| Center they _shouldn't_ be locked away in cabinets.
| nmcfarl wrote:
| They should have just paid for yellow routers.
|
| -
|
| 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.
| 15457345234 wrote:
| Yeah, it seems odd.
|
| 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.
| jameshart wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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!
| kjellsbells wrote:
| 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.
| sgu999 wrote:
| 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.
___________________________________________________________________
(page generated 2023-12-10 23:02 UTC)