Tools and strategies for transition
Radical computer software architects have been using pattern languages with dramatic effectiveness for several decades, thereby revealing a likely missed opportunity for architects of the built environment. The reasons are intriguing – and, we suggest, point us toward promising new prospects.
Among architects, the idea of a pattern language for design – most closely associated with Christopher Alexander’s image-rich 1977 book of archetypal design models – has a murky reputation. While many architects admit privately to being deeply influenced by the book, some prominent architects have offered heated critiques.
But evidence shows that they are overlooking a powerful resource. Perhaps too, they may be revealing something about the lingering weaknesses of modern architecture itself: its ideological rigidity, its insistence on the privileges (if not irresponsibilities) of a fine art, and its failure to take seriously an evidence-based approach to design.
The criticisms from architects seem to fall into three overlapping groups. Some critics don’t like A Pattern Language’s allegedly romantic bias. Some question its efficacy, and imagine it to be a kind of failed 70’s hippie experiment, from which the world has moved on. Some dislike the very idea of a set of restrictions on the creative explorations of designers. After all, how can the process of design be reduced to a series of formula-like patterns?
But evidence from the software world suggests they are missing the point. More than that, they may be missing a remarkable new opportunity. But lest we think other architect-critics are solely to blame, those who advocate pattern languages need to apply a corrective evidence-based approach to their own failing ways too.
For this powerful opportunity can only be seized, let me suggest, if several key changes are made to the way patterns and pattern languages are developed and applied. These lessons are on visible display in the stunning success of software designers in using the very same pattern language technology.
It may surprise you to learn that you are already almost certainly using pattern language technology every day to solve routine problems within your environment. If you use iPhone apps to find your way or track your gas or do any of the thousands of other things that iPhone apps can do, you are using pattern languages. Indeed, if you use any kind of Mac (as I myself am doing in writing this essay), then you are using pattern languages. If you use computer games, or many other computer programs, you’re using pattern languages. If you use Wikipedia or other forms of wiki, you’re using a technology that was a direct spinoff of pattern language technology.
A quick Google search illustrates the comparison. Google “pattern language” and you get (or I did, in July 2011) 487,000 hits. A lot, surely. But Google “design pattern” – the software term for pattern languages – and you get 5,850,000 hits – about a twelve-fold increase.
Bear in mind, too, that the search term “pattern language” includes hits for architectural pattern languages, AND pattern languages of other kinds. Within this burgeoning field, and in addition to software patterns, we can find pattern languages for economics, organization theory, business management, biopogy, ecology, and many other fields. One of the most fascinating developments is in molecular biology, where pattern language models are helping to explain the synthesis of nucleic acids, and even the emergence of multicellular organisms (Newman and Bhat, 2009).
The diversity of this success may be rooted in the universal design issues that Alexander sought to take on in his groundbreaking 1964 book, Notes on the Synthesis of Form. How can a design problem be decomposed into its characteristic elements, and how can these be recombined into a functional design solution? Which configurations (or “patterns”) regularly recur, and can therefore be expressed in repeatable clusters? How can these clusters be assembled using grammar-like rules? The answer was the essential structure of pattern languages.
The comparison to language was more than an analogy. When we use language, we are doing something similar – expressing the relations between repeated patterns of events, coded into words and sentences. The grammar we use in language allows us to create webs of meaning that transcend the list-like string of words that we actually utter. The power of language is at its richest when we create the interlinking meanings of poetry.
We have done much the same thing, Alexander realized, in constructing our built environments. We have shared linguistic concepts about the recurrent elements of the human built environment – the building types, expressive details, construction systems, and all the other parts of the design and building process. We have refined, transmitted and regenerated these elements in new combinations, through the linguistic processes that guided the “culture of building.”
How did pattern languages come to dominate in the software world? In the beginning, a few radical software engineers (in particular, the pioneers Ward Cunningham and Kent Beck) immediately saw the advantages of pattern languages for their own work. A central challenge is to translate the list-like sequence of computer code into something more like the web-like structure of language. This is because, after all, computers are not made to solve computer problems, but rather, human problems. Those problems are defined by the domain of language: the capacity to express structural relationships that are of interest to us, and that we may want to transform or alter in particular desired ways. (Say, “I want to make sure there is money in my bank account, and if not, I want to put some more in.”)
Pattern languages are therefore remarkably suited for this human-centered problem-solving, using the information-processing capacity of computers. “Design patterns” (as they’re called) are essentially clusters of computer code, aimed at solving recurrent sub-problems. Put them together with grammar-like rules – or better yet, let the computer do it, interacting with the user – and you have a computer software system that is much more flexible and varied, like the capacity of language itself. The same simple elements (letters, words, phrases) can be used to make dry technical lists, or the poetry of Shakespeare. It can be put together into complex structures that usefully model existing realities, and then generate new realities.
So why has this remarkably successful technology proved so limited in architecture, the very field for which it was created? Are architects simply weird? Or are pattern languages somehow inefffective when it comes to the built environment, but effective in all these other fiends for which it was not intended? That would seem to be an odd development indeed.
Or is it perhaps (as we suggest) that this situation illustrates an important transformation going on in culture – but one that has not yet been exploited by architects? Is there a golden opportunity for architects to do so?
The transformation, we suggest, is reflected in the new methods pioneered by software engineers: open-source development, peer-to-peer collaboration, and network technologies. It is echoed in Alexander’s own pattern language technology – but not fully realized there.
For one thing, there is the problem of the book – a mesmerizing tome of 253 patterns that seem fixed into an almost biblical text. By contrast, the software engineers have tens of thousands of patterns, not made by one small team led by one dominant personality, but by thousands of individuals who have never even met, and who work through collaborative wikis.
For another thing, as Alexander himself has pointed out, the patterns need to be customized into languages that are project-specific. When Japanese carpenters built traditional tea houses in the past, it was not with a series of generic patterns, but with very specific patterns that had been refined and adapted to the specific task of building tea houses. The “genetic script” had become highly customized.
Some colleagues and I have been developing and applying “Project Pattern Languages” for clients, and the results have been very useful and promising. A number of others are doing this too. The architect Tom Kubala of Kubala Washatko Architects has a repository of some 700 patterns developed for clients, and able to be adapted into new project pattern languages for other clients. A number of listservs (such as the Building Process Network) and other organizations are doing similar work. I am myself aware of work at universities in the US, UK, Mexico, India, Israel and Romania, to name a few.
But far more needs to happen, if we are to see the real power of collaboration and networking that our software colleagues have realized. Let me suggest the following set of priorities:
We need many more people writing
many new patterns, and new kinds of patterns (including processes, geometries, economic tools, etc) — and with the skills to do so.
We need a new emphasis on “Project
Pattern Languages” (PPLs), which bring together a customized set
of patterns for each project. We also need many people with the
skills to do this.
We need new open-source
repositories, which can share and exchange these new patterns.
We need built examples, and a
growing base of concrete experience and evidence.
We need a spirit of
inter-disciplinary collaboration and pragmatism – able and willing
to draw useful lessons from other fields of design and human
The last goal may be the most difficult, because it may require a transformation in the way that most leading architects think about their craft, and the way that most architecture schools teach that craft. Is architecture a fine art, a supremely creative act of innovation from nothingness? It it a privileged act of “architectural culture” among a rare set of selected star practitioners? Or is this a kind of delusion, masking the real purpose of architecture in an aging technocracy – to provide an entertaining and respectable veneer over what is essentially a standardized act of industrial product design? (As some leading architects freely admit – notably Rem Koolhaas?)
If so — and if architects truly want to be avant-garde — then perhaps they should use the tools available to challenge this unsustainable and decaying old regime, wherever they might find them.