Why a Programmer Might Actually Be a Good Urban Planner
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 it's just the metaphors created in different times by different disciplines and none of them conveys the full specialization that «software engineers» have a 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 a so-called «real world» has its limitations. For example, in a crowded city, we can't put the 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 a large number of smallest possible amends distributed over time.
Off-topic
That's starting to be actually similar to software engineering - we code until something pops up and we can't do it anymore unless we rethink the system. That's why they say «the perfect project is the project that's not being made». But that's not a consequence of something specific to software engineering, urban planning, or engineering. Instead, it's something specific to all human activities - you can't predict every step in the future, just as you can't predict the weather.
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 this 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 to «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 possibility to scale the system vertically(adding more relations between elements) and at least the same amount of possibility 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, 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 it 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 the AI which already spans trillions (!) of parameters.
As it seems we have some features of the software development domain that are «superior» to the urban domain: complexity, abstractness, and specialization capabilities, while others are «inferior» and we have something to get from it: an evolutionary approach to management and huge lifespans.
* That's the property of the internet and computing in general that social media takes its roots from. Here's the talk by Zuckerberg: timecode.
** Nevertheless I haven't found any valuable estimations or even comparisons, or just a mere method of calculation of complexity or abstractness of both cities and software. We need more research on that!
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 switch on our decisions afterward. At least to a much greater extent than in a 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
The concept of pattern language was first introduced by architect Christopher Alexander in his book «A Pattern Language: Towns, Buildings, Construction» published in 1977. It was a tool for architects and urban planners to create coherent and functional designs. The idea was to identify and describe successful design solutions as patterns, which could then be applied in different contexts.
Anything familiar? Right! That's our ordinary «Design patterns».
In the 1990s, the software engineering community began to adopt the concept of pattern language as a way to improve software design. The book «Design Patterns: Elements of Reusable Object-Oriented Software» by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, published in 1994, popularized the idea of using pattern languages to document and share successful software design practices. Since then, pattern languages have become an important tool in software engineering, helping to create more modular, reusable, and maintainable code.
Christopher Alexander, the creator of the original «patterns», passed away last year. I still recall his words in one of the talks:
This is a pretty strange situation I find myself in. I hope you sympathize with me, I'm addressing a room full of people, a whole football field full of people and I don't know hardly anything about what all of you do.
So be nice to me
Him being the creator of the concept 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 may someday help us make a better living for ourselves and the ones around us. A famous one once said, «knowledge lies in comparison» (in my interpretation). And I firmly believe that by changing the viewpoint we can often solve problems that weren't capable to solve with our previous toolset.
Anyways, I hope that I've provided arguments in favor of the similarity of these fields. And for those of you wondering what practical applications these pretty abstract thoughts will make, I'd recommend checking this short Telegram post in my channel about Computer science.
Member discussion