Pages from the book A Pattern Language.
“[A Pattern Language] could very well be the most read architectural treatise of all time, yet in the architecture schools I know, it is as if this book did not exist.”
— William Saunders, Editor, Harvard Design Magazine
Many architects know the idea of pattern languages only through the book of 253 patterns by that name, written in 1977. A number of practitioners have written additional patterns (including this author) but they remain largely as supplements to the original primary collection. Aside from some recent work that originator Christopher Alexander himself has done, as yet there is nothing like a major new development of pattern languages in the field of architectural design. In spite of the book’s perennial popularity, pattern language methods have had limited application in education and practice.
The state of affairs in architecture is in striking contrast to the software engineering world, where the same pattern language technology has had, it is fair to say, a ubiquitous and industry-wide impact. Even more telling may be the fact that most architects are ignorant of these developments.
I will argue here that this fact illuminates a major undeveloped opportunity for architects, and for others who are interested in related advances.
In a surprising disciplinary cross-fertilization, Alexander’s Pattern Language technology has become the foundation for a major pattern-based movement which has spawned an enormous corpus of work, centered around so-called “design patterns” or “pattern languages of programming” — a highly influential class of object-oriented software programming methods. In turn design patterns were integral to the development of Wikis (one example of which is Wikipedia); simulation games like The Sims and Spore (and much other gaming technology); the Cocoa programming language on which iPhone apps are created; Agile software development; Extreme Programming; and others.
Indeed, in taking stock of the development of pattern languages, an astonishing fact emerges. The activity in the realm of software dwarfs that of architecture — so much so that a recent Google search yielded about 250,000 hits on “pattern language,” but almost 5,000,000 hits on “design patterns” (only one of the software fields). This twenty-to-one ratio is telling.
Nor is the growth in pattern language technology confined to software. Within computer science it can also be found in information management, human-computer interface, systems architecture and other related fields. Pattern language scholarly work can also be found in sociology, organization theory, economics, education, ecology, molecular biology and other fields. (This also means that the 250,000 Google hits cited above would be even smaller for architecture alone: it seems that more than half that number is accounted for by these other fields.)
Some of the most fascinating applications now being explored come from “hard” sciences like molecular biology. In one notable example, Newman and Bhat of New York Medical College proposed a “pattern language” model for the development and evolution of multi-cellular form, of the sort that occurred during the so-called “Cambrian Explosion” that gave rise to many modern animal forms. (Newman SA, Bhat R., “Dynamical patterning modules: a “pattern language” for development and evolution of multicellular form.” Int J Dev Biol. 2009;53(5-6):693-705.)
What are the lessons for what must be, for architects, a humbling comparison?
First, there is the possibility that the real usefulness of pattern languages simply does not apply to the field of architecture. But it would seem rather unlikely that a technology developed in one field is of so little use there, but of such enormous use in other unintended disciplines. It seems more likely that something has blocked the development of pattern languages in architecture to the same degree.
Along those lines, another possibility may be that many architects have mistaken A Pattern Language as solely a finite set of architectural prescriptions, and failed to grasp the potential of its deeper structural logic in the way that computer scientists did. This aversion may be especially emotional among architects, because any such finite set of prescriptions, however generative in nature, is commonly assumed to place an unwarranted restriction on the designer’s unfettered capacity to create novelty. Such a line of thinking can be found in some of the more acerbic criticisms of pattern languages in architecture, such as those by Alexander’s Berkeley colleague Jean-Pierre Protzen, and Harvard Design magazine editor William Saunders.
Yet another possibility may be that architects — including Alexander himself, perhaps — have failed to adopt the collaborative, “open-source” methods of other disciplines. Whereas software designers immediately began sharing ideas about tinkering freely with pattern languages — even exchanging them between highly competitive companies such as Tektronix, IBM and others — architects have treated patterns as proprietary, and largely immutable. That is, either one applies the original 253 patterns, with perhaps a limited application of one or more additional patterns, or one abandons the technology altogether. But in no case does one “open the hood” and re-use the core system to develop all manner of new approaches, in the way that software designers have done with such evident zeal.
To understand the power of pattern languages — and their potential for a renewed application to the field of architecture and urban design — we must return to the core structure of patterns, and the problem it was originally meant to solve. As we saw in the last chapter, it has its roots in Alexander’s first major work, Notes on the Synthesis of Form (1964). As he explained in the introduction to the tenth-year edition to Notes:
The idea of a diagram, or pattern, is very simple. It is an abstract pattern of physical relationships which resolve a small system of interacting and conflicting forces, and is independent of all other forces, and of all other possible diagrams. The idea that it is possible to create such abstract relationships one at a time, and to create designs which are whole by fusing these relationships--this amazingly simple idea is, for me, the most important discovery of the book.
So the structure of a pattern was very simple, and yet the results of this kind of fusing of relationships could be, no less than traditional built environments often were, highly complex. This theme of simplicity-generating-complexity is echoed in much of complexity science, where simple processes can generate, through adaptive iteration, the unfathomably complex (and often irreducible) structures of the natural world. (This is seen, for example, in the highly complex patterns of fractals as they are generated by computers, and in natural formations like clouds, sand dunes, etc.)
There is a corollary with languages, which have a limited set of words, and yet produce a vast set of complex meanings. The relationships between words are not mere linear ones (as, for example, in a mere list) but rather, they form a mesh-work of complex interrelationships (as, for example, in poetry). Again, while there are nested hierarchical relationships, there are also overlaps, cross-linkages, and ambiguities.
Patterns are not needed for every structure in the built environment, or within any other design problem. In fact, their number could quickly become vast. Patterns are only needed for the most prominent configurations of needs, or what Alexander calls “forces.” The pattern represents a workable resolution of the forces, as they tend to group together into strong clusters. Different patterns are only weakly related to each other, and therefore they can be combined and recombined with other patterns in a useful way.
A simple example will help to illustrate the logic. (Indeed, this example is so simple that it would not need to be articulated, and so is not included in any known pattern language.) Consider the pattern “Door”. In its most common form or pattern, a door typically has hinges on one side, and a knob with a latch on the other.
Figure II.2.1. A simple pattern “door” might consist of the pattern of relations of the two hinges and the knob and latch, and how they are required to be arranged as a set of “strong forces.”
These elements are related to each other in what Alexander would call “strong forces.” That means that the hinges and the knob have to be structured in a particular way, with the hinges on one side, and the knob and latch on the other. That constitutes the “pattern” of the door. We can readily see that changing this configuration would be problematic!
The pattern “Door” can also be related to sub-patterns, such as “Hinge”, “Knob”, “Latch” and so on. Each of these can be further related to sub-patterns, “Screws”, “Pin” etc. But they are not strictly related, and we can make various flexible substitutions. It is in this sense that Alexander refers to “weak forces”.
Going up the scale, we can also see that the pattern “Door” might be related to the pattern “Room” and the pattern “House” and so on. These too are “weak forces” — we might have two or three or more “Doors” within one “Room,” and one “Door” might connect to two “Rooms.” These are the overlapping network-like relationships between the environmental spaces of a city or a building, and between the patterns of its design.
So a pattern is just this — the cluster of “strong forces,” within a larger network of weaker forces. The clusters themselves form the patterns, and then these patterns can be combined and organized within larger collections, but keeping the essential connections of forces that resolve the problems.
Figure II.2.2. The “patterns” are the clusters of “strong forces” that are embedded in a larger network of “weak forces” — just as, say, a “door” can be weakly related to another door in the room, but its hinges and knob are strongly related to each other.
For those who don’t already know the book A Pattern Language, I recommend that you peruse the book if you can, and this structure will become much more self-evident. In the meantime, for our purposes, I attach here photos of one of the patterns from the book, showing how it works in an urban context.
Figure II.2.3a. The pattern “Paths and Goals” begins with its title, and an iconic photo to set the context.
Figure II.2.3b. Next the pattern lays out the context of “upward patterns” with titles that serve as “hyperlinks” (although not literally so, of course, since the book has only appeared in print, and was made before computer hyperlinks were in common use). It then defines the problem, followed by a section that explores the structural nature of the problem as a system of elements. This section can include references to other works, analytical sketches, or other materials.
Figure II.2.3c. Finally, the pattern states a conclusion with the essential elements of the resolution of the “forces” as a structural configuration. Below the conclusion is another section of “hyperlinks,” this time to “lower” patterns, i.e. those at smaller scales, or that occur as sub-problems to the pattern.
The structure of a pattern, then, is a straightforward one:
The upward and downward hyperlinks establish any given pattern within a nested hierarchical structure. But crucially, once again, this structure is not rigidly hierarchical, but also allows overlap.
As the patterns are combined into a system, these overlapping relationships create the “thicker, tougher, more subtle and more complex” kind of structure that Alexander observed in natural cities.
Alexander’s critique of conventional practice —
and its implications
As I discussed in the last chapter, Alexander’s innovations were aimed, from the beginning of his career, at the chief failing that he saw in conventional practice: the inability to create successful adaptations to the natural overlapping complexity of actual design problems. Yet as he argued in “A City is Not A Tree,” this is a perennial problem in modern planning, whose designs do exhibit a damaging tree-like structure. This was because, he argued, the rational mind inevitably defaults to these neater, more easily managed categories of thought. In this sense, pattern language technology was aimed very directly toward plugging a very real gap in modern design — one that amounted to a major technological shortcoming of modern methods.
It is not so surprising, then, that since Alexander was dealing with design as a broad topic, and not merely with architectural design, his solution did indeed have great relevance for other fields of design too, notably software design. These designers, too, needed to translate a very serial, hierarchical kind of process into a more usefully networked one. As software pioneer and Wiki inventor Ward Cunningham has documented, he and his colleague Kent Beck quickly realized that Alexander was onto something that they needed. It required extensive adaptation and customized structuring for their needs, but the gist of it was very much what their challenge required.
In software as in architecture, the goal was to preserve the context, the aspect of wholeness or “gestalt” in which the problem is embedded, the better to resolve the real problem and not create new problems along the way. (This is a common “unintended consequence” of many design activities: just when one problem is solved, another one pops up.)
The book A Pattern Language was the first major demonstration of pattern languages in architecture, and it was an enormous bestseller. (As William Saunders noted, it “could very well be the most read architectural treatise of all time.”) The book certainly had a great appeal, and clearly evoked a broader feeling of what the human environment can give to us.
More poignantly, it had the ability to evoke qualitative aspects of the built environment, at precisely the same time that it spelled out quantitative aspects. Make the balcony at least this many feet deep. Make the public space this wide. And so on.
This was a remarkable feat: it united the quantitative and the qualitative, within a manageable network of design actions and structural relationships.