I’ve long been familiar with the idea of software patterns. But I didn’t connect it to its roots in the architectural writings of Christopher Alexander until I recently listened to Kent Beck’s keynote at the 2008 Rails conference. Kent was deeply influenced by The Timeless Way of Building. That book wasn’t available in my local library. But the companion volume, A Pattern Language: Towns, Buildings, Construction, was. It’s been a revelation to read it for the first time, more than thirty years after it was published, through lenses formed by my experience with software and networks.
Here’s how A Pattern Language summarizes a pattern called FOUR-STORY LIMIT:
Therefore, in any urban area, no matter how dense, keep the majority of buildings four stories high or less.
And here’s how the Portland Pattern Repository summarizes the Singleton Pattern:
Therefore, let the class create and manage the single instance of itself, the Singleton. Wherever in the system you need access to this single instance, query the class.
The stylistic allusion shows a direct literary influence flowing from architectural pattern language to software pattern language. Alexander’s book, by the way, is a pre-Web hypertext. The pattern called FOUR-STORY LIMIT (21), for example, refers to NUMBER OF STORIES (96), DENSITY RINGS (29), BUILDING COMPLEX (95), HOUSING HILL (39), and HIGH PLACES (62). Each of these numbered patterns links to a set of related patterns, as does each page in the Portland Pattern Repository — which was also, of course, the Ur-wiki from which all things wiki are descended.
I suspect we’ve yet to fully elaborate the connections between software, architecture, and networks. Consider these pattern names from Alexander’s 1977 book:
These evocative names, and the sketches that accompany them, arise from a deeply network-oriented way of thinking. Many of the higher-level patterns express core values about connectivity and decentralization. And those values resonate more powerfully now, in our Net-aware world of 2010, than they might have in 1977.
Some of the prescriptions in A Pattern Language can seem absurd. For example, Alexander argues that an optimal urban core should serve a “catch basin” of about 300,000 people, that these cores should be widely distributed, and that each should specialize in some way that makes it world-class. Why?
The problem is clear. On the one hand people will only expend so much effort to get goods and services and attend cultural events, even the very best ones. On the other hand, real variety and choice can only occur where there is concentrated, centralized activity; and when the concentration and centralization becomes too great, then people are no longer willing to take the time to go to it.
Which is fine in theory, but we’ve already built megalopolises surrounded by suburbs. It’s not like we can do it over.
Except when we can. In America the most striking examples are in Michigan where I lived for many years. Detroit, once a city of two million, is being recreated as a city that may end up at less than a third that size. What will become of the rest? It just might be plowed into farmland. If so, a pattern called CITY COUNTRY FINGERS may turn out to be a useful guide.
Likewise there are plans afoot to gather the remaining population of Flint into a few viable neighborhoods and let the vacated land become parks and forests. If that happens, many of the ideas in A Pattern Language, about how to organize neighborhoods and their transportation networks, could come into play.
In Asia, meanwhile, entire new cities are being built from scratch. I recently met an engineer who works for the global consulting firm Arup. For one of their projects, he told me they’re using a simulation of wind flow as one of the constraints on the layout of streets and buildings. The layout is also informed by RING ROADS and LOCAL TRANSPORT AREAS, patterns that yield a tiered distribution network which optimizes the use of delivery trucks.
Networked software is highly malleable, and we take for granted that we can try out different design patterns. The built environment rarely affords the same opportunity. But in this century of urbanization, as circumstances force us to rethink our energy, transportation, and settlement networks, it may turn out to be softer than we suppose, and more open to the influence of pattern languages.
An interesting follow-up for software developers interested in lessons to be learned from architecture is Stewart Brand’s How Buildings Learn. It’s about how existing builds change and evolve after they’re built, a part of the process that architects rarely, if ever, think about.
While you’re right about the malleability of software relative to architecture or city planning, I think that difference makes it easy to forget how much of a nightmare it is to change legacy systems to keep them living and flexible through changing use. Even more than architects, maybe, developers love to build something fresh rather than maintain something existing.
Brand did a great documentary presentation of How Buildings Learn that’s fully available on Google video. Kottke linked to all of the episodes here: http://kottke.org/08/08/how-buildings-learn-tv-series
Imagine if developers knew as much about the Romance of Maintenance (one of the chapter titles) as people involved with buildings do…
— Greg
As many people have observed, the choice of the term “software engineering” back in 1968 may have both reflected and reinforced a less-than-useful conception of what it is that we do: in practice, we seem to have more in common with architects than with engineers.
An interesting follow-up for software developers interested in lessons to be learned from architecture is Stewart Brand’s How Buildings Learn.
Absolutely! Thanks for mentioning that, I had intended to. I’ve also recently read it for the first time, and it struck all kinds of sparks. Among other things, it prompted me to write this on Twitter:
[Software learned how to use patterns from architecture. It’s a shame that architecture hasn’t reciprocated by learning how to use tests.]
A couple of times lately, once in conversation with a consulting engineer and once in that book, I encountered the observation that “post-occupancy evaluation” may be to architecture what testing still too often is to software: a custom “more honor’d in the breach than in the observance.”
Brand’s emphasis on separation of concerns — Structure from Skin from Services — is another example of something that architecture mostly hasn’t yet learned from software.
in practice, we seem to have more in common with architects than with engineers.
Although if what architects of software and the built environment share in common is involvement in planning and construction, to the exclusion of ongoing evaluation, maintenance, and adaptation, then maybe engineering is the right discipline to affiliate with.
Or, hat tip to Greg Wilson, carpentry.
The idea of architects being able to continuously follow up with the residents of their buildings the way (the best) software developers do is a great one.
Overall, though, I’m not sure who has the greater claim to maintainability. We’ve yet to see software last more than a few decades let alone thousands of years. Somehow, I find it hard to imagine it doing so.
Another really interesting tidbit from Brand for comparison is the idea of colloquial architecture, i.e. that the best buildings are the ones not built by famous name architects, but built simply for practical use in a way that let their occupants change and improve and finish them so they would gradually coevolve with their use.
When it comes to software, a lot more people seem to live in the equivalent of decaying housing projects that they can’t maintain themselves (i.e. social networks) rather than the simple new england farmhouses and bay area houseboats that they can own and love and improve for generations.
I guess the equivalent of colloquial architecture is every php or Perl application ever built. This brings to mind Tim Bray’s recent post about everything that’s wrong with software today. I imagine there are similar diatribes within the architectural community.
I’m not sure PHP and Perl apps support the point about the adaptability of colloquial architecture. A key example in How Buildings Learn is timber framing, which achieves a separation of concerns: Structure from Skin from Services.
I’d be more likely to advance HTTP and REST as the colloquial architecture of the Web era, and as the software analog to timber framing.
Don’t worry about finding The Timeless Way of Building. a Pattern Language is much better!
That’s good to know. It is a remarkable book. Among other things, a treatise on the network topologies of human settlement.