Why a Programmer Might Actually Be a Good Urban Planner
Exploring urban planning as the metaphor of programming.
Have you ever considered yourself an engineer, designer, or architect? Maybe you consider yourself a computer scientist as I do. Well, that’s all interesting but what if I told you that they’re just metaphors created at different times by different disciplines and none of them conveys the full specialization that «software engineers» deal with on an everyday basis? This pluralism of approaches towards our relatively young domain may mean that it’s a handy technique for developing fresh ideas in the field.
So recently I’ve discovered an article by my favorite CS writer - Tomas Petricek: Where programs live Vague spaces and software systems. In brief, he focuses on his recent developments in metaphors of programming. And this time it’s all about urban planning metaphor. But can it possibly fit into a list? Let’s try to find out.
Virtual space
The first and biggest difference between our domains comes from the different spaces. The physical space, or the so-called «real world», has its limitations. For example, in a crowded city, we can’t put a new building right in the center, because there can’t be two objects in the same spot. Consequently, the interaction between parts with distant geographical locations is problematic at best. So our choice of new buildings/public spaces and other objects in the city is not made solely by our will. Rather it’s being made by constraints that the city, frequently intentionally, puts on us.
By saying «intentionally» I mean that the architects of the street/district/whole city had their plans for its life and there’s nothing you can do about it but make a large number of the smallest possible amendments distributed over time.
So, yeah urban planning is more of a rigid structure, while in the software domain, you can create adapters, facades, and other patterns that will help you to (temporarily) overcome these limitations.
Degree of abstractness
And that’s where we come to another difference. Computer programs are abstract and, in fact, might be the most abstract things in human history(although Immanuel Kant might doubt it).
An antonym of «abstract», as it is known, is «concrete», and that’s to say that cities are made of concrete. So with the pun fully intended we can safely say that there is a major difference (in favor of software systems) in the ability to scale the system vertically(adding more relations between elements) and at least as much ability to scale it horizontally(adding more elements).
Complexity and timelines
Cities operate on a truly gigantic scale. It is obvious that the history of a city and its cultural and sociological heritage are huge. And most modern cities have some common characteristics:
- Enormous timelines. Unlike software which is a very young discipline, modern cities span hundreds and thousands of years.
- The city won’t be created just out of anything. It’s a long and complex evolutionary process. While software in its current form is being made only under the orchestration of a group of people. It’s made artificially, even more artificially than cities 😅.
- The city has to make do with different audiences on the same resources. For example drivers, bicyclists, pedestrians, and let’s say, disabled people. The software can specialize. It divides the functionality for different users into different virtual spaces. It’s a consequence of the previous «Degree of abstractness» and «Virtual space» points.
- The consequence of huge timelines is the city’s huge complexity. But as to software and especially regarding its smaller timelines I think it’s safe to say that software should be much more complex over time. Especially if we take into account AI, which already spans trillions (!) of parameters.
Development process
It was tackled in the previous point a little bit, but here I want to emphasize that due to the «Degree of abstractness» and «Virtual space» points we now have a situation where we can do our job iteratively and it will frequently be possible to go back on our decisions afterward. At least to a much greater extent than in the design of a city.
Urban planning projects typically involve a long-term planning process, with multiple stakeholders and public input, while software engineering projects can have a more iterative development process with shorter development cycles.
Discipline’s common history
Anything familiar? Right! That’s our ordinary «Design patterns».
Christopher Alexander, the creator of the original «patterns», passed away last year. I still recall his words in one of the talks:
Him being the creator of the concept that people from so many different fields use, I value his work a lot.
Final thoughts
With the major point being the difference in the space used in different domains, we could deduce others:
- Degree of abstractness
- Complexity and timelines
- Development process
- Common history
Who knows, maybe these comparisons will someday help us make a better living for ourselves and the ones around us. Someone famous once said, «knowledge lies in comparison» (in my interpretation). And I firmly believe that by changing the viewpoint we can often solve problems that we weren’t capable of solving with our previous toolset.