Cities and Programming
Source: On architecture, urban planning and software construction by Tomas Petricek
Mostly about maintenance of cities and parallels with maintaining software.
See also: Urban planning
# XAI systems
In the last case (organized complexity and non-repetitive digital systems), the complexity of the problem cannot be reduced - we need to consider a large number of interacting processes or components. At the same time, all of them are equally important and play an important role in some aspect of the system. As Jane Jacobs puts it, the large number of interrelated variables form an organic whole. This is the end result of emergent behaviour
Importance of explainability
# Maintenance
Almost no buildings adapt well. They’re designed not to adapt; also budgeted and financed not to, constructed not to, administered not to, maintained not to, regulated and taxed not to, even remodelled not to. But all buildings (…) adapt anyway, however poorly, because the usages in and around them are changing constantly.
Open-closed principle
How do we build software so that it gradually and gracefully degrades rather than abruptly stops working? Just like software systems, any building built using any kind of materials requires some creation vs maintenance over time. And just like with software systems, building owners are often bad at performing the necessary maintenance.
The idea of chaos engineering is perhaps a first step in this direction.
Rebuilding the Ise Grand Shrine: retaining knowledge through constant revision
vernacular design restricts the scope of the problem by limiting architectural ideas to what is typically used in the local context. This reduces the design task and allows the builder to focus on skilful solutions to specific problems rather than at reinventing forms.