Oct 7, 201101:15 PMPoint of View
The Pattern Technology of Christopher Alexander
Patterns provide information about a design configuration that solves a recurrent problem -- such as the geometry of a walking network, or a path shape.
Some architects are big fans of the book, A Pattern Language -- a compendium of 253 “patterns” that cover elements of environmental design, spanning the scale, from regional planning down to construction details. As we have noted here before, this book triggered a surprising explosion in software technology, and spawned a new class of software called “design patterns”. That software now helps to power Macs, iPhones, most games, and many other computer systems. The open-source platform Wiki, and its many applications including Wikipedia, was another direct (if surprising) spinoff of the technology. Many other fields have begun using pattern language technology successfully, including molecular biology, economics, product engineering, organizational management, and service design, to name a few.
This remarkable cross-disciplinary transfer of knowledge happened because software engineers saw an insight in the work of an architect that proved very useful. The story of how this happened is fascinating. It may also challenge the conventional design thinking of many architects. In 1987, Ward Cunningham was a software engineer working on new software approaches at Tektronix Corporation in Portland, Oregon. That year, he recalls, programmer Bill Croft sent him (and several other computer pioneers) a copy of Alexander's book A Pattern Language. Coincidentally, another friend and former colleague, Kent Beck, then at Apple Computer, had acquired copies of Alexander’s other classic design books, Notes on the Synthesis of Form and The Timeless Way of Building. Croft, Cunningham, and Beck remember being excited by Alexander's work, and a feverish collaboration began between Cunningham and Beck to develop new software technology from the architect’s ideas.
The work soon widened to include hundreds and then thousands of collaborators, working in conferences, symposia, books, and on-line – especially through a customized new collaborative gadget invented by Cunningham just for that purpose, called a “Wiki.” (He says the name came to him as he was waiting for a shuttle on his honeymoon in Honolulu – called a “Wiki Wiki,” which is Hawaiian for “quick.”) What was the revelation? How did these two theoretical books on architecture (dismissed by some architects as too “touchy-feely”) strike three different, hard-nosed engineers as useful and even breakthrough material?
We have to remember that software engineers, by nature of their work, have a big problem. Their job is not to solve problems for computers, but for human beings; the computers are only tools in that process. But computers are, in effect, idiots that only do what they’re told. So the software has to be organized in a way that follows the patterns of human beings -- and human life. Achieving that, however, is supremely hard, because software is really nothing other than long lists of instructions. It has to be given the capacity to behave more like a language -- more like the web of meanings that is the characteristic of human life. To be really effective, it has to do more than process a collection of parts: it has to work with wholes. It has to solve human problems, which are problems involving whole systems.
In fact this is the very problem that Alexander himself set out to solve when he developed the technology behind pattern languages, in his original PhD research at Harvard University, later documented in the landmark 1964 book Notes on the Synthesis of Form. Some design theorists consider that book a great contribution in itself, but it is not well known by lay people. Yet the key idea behind it is simple and powerful -- and as we have been discussing, it represents a radical transformation in design technology. To understand this, let’s consider a simple comparison. Imagine that you have two pieces of paper in your pocket, each of which has a string of words. One of them is a grocery list:
An example of a simple hierarchy: a grocery list
Then imagine that on the other piece of paper in your pocket is another string of words (a famous poem by William Blake): O Rose thou art sick. The invisible worm, That flies in the night In the howling storm: Has found out thy bed Of crimson joy: And his dark secret love Does thy life destroy.
An example of a much more complex kind of language: William Blake's famous poem "The Sick Rose" -- illustrated personally by Blake and his wife Catherine.
These are obviously different kinds of strings of words. But here’s the interesting question: what is the difference in the structural way these two strings of words are put together? The first set of words is a hierarchical list. “Corn flakes” and “bananas” go under “food.” “Food” goes under “grocery store.” That’s a hierarchy: The tree trunk has branches, which each have twigs.
While the components of a tree are interconnected into a working whole, the hierarchy of the grocery list is one of simple inclusion and stops there. That’s about the only connection the words have to each other. The second set of words has a much more complex relationship. “Rose” and “art” go together following grammatical rules, which describe some kind of complex action. “Sick” is somehow the output of that action. “Thou” indicates a grammatical relationship suggesting that the speaker is seeing the rose in front of him or her. Other words also convey very subtle shades of relationships between the parts, which help us to model this reality of roses, worms, sickness and so on, and their complex layers of relationship. And to make it all even more complicated, it appears that the “rose” may not be a rose after all, but a person, or a general symbol for sickness!
That’s the power of poetic meaning, which can contain ambiguity and multiplicity of meaning -- all relevant to human experience, and human value. So this little passage is packing a lot of overlapping layers of significance! It’s able to do that because it has the power of language: that is, the power of grammatical structures that can express networks of whole meanings. Individual words can bridge over their rigid place in the series of utterances, and cross-relate. “Art” is not “sick” -- “rose” is! We could diagram all the multiple network connections among the words in this short poem, especially the more obvious ones. However, other much more subtle connections generate images, trigger remembered moods and subconscious feelings of relationships in our mind and those, in fact, immerse us emotionally in the poem.
The power of the message lies in the multiplicity of coherent subsystems of meaning that the words connect. This turns out to be an extremely important quality of language. It allows us to map the meanings of things beyond simple hierarchical relationships, and describe the varied aspects of wholes -- even complex emotional wholes without a simple literal meaning. We can describe the poignant decline of a rose, and many other complex aspects of a subtle and transitory reality. And somehow, we can capture something important and real to our own lives. What does this have to do with the hard-nosed world of engineers? Quite a lot, it turns out. What the software people had at the time of the Pattern Language were more like grocery lists, and very far from poetry: that is, they had lists of disconnected instructions, operating mechanically. They could talk about “Get rose spray” but they could not describe the more complex aspects of rose illness, or how to respond to it.
It was a bit like the limitations of early computer users, who had to input long series of text commands, in comparison to mouse users, who can skirt around the page, pointing and clicking, to complete the complex weave of tasks that are of interest to humans, not to machines. What excited both Cunningham and Beck was just this: they thought they might have stumbled upon an idea that could convey this kind of delicate inter-relationship in their software, which would allow it to follow more closely the kinds of things that real human beings are interested in doing. Perhaps these users wanted to play a very complex game, or solve a very complex problem. Software that is written in this pattern-like way might be able to convey wholes -- whole configurations of ideas and solutions to things, which could be combined in a more flexible, powerful, language-like way. So this was, in a sense, a kind of poetry in software. It is important to understand that patterns don’t replace the design process with an automated solution. The designs don’t just “pop out.” Rather, the patterns incorporate the information about previously successful solutions, in a way that designers, working adaptively and in a human scale, have more ready access to it. In this sense, the patterns are a tool for a very important concept known as “evidence-based design” -- design that is well-adapted to solve human problems, and to meet human needs.
The design is not the product of a linear mechanical process, but emerges from a process of mutual co-adaptation, proceeding in evolutionary cycles, with the information on successes transmitted in a DNA-like message. Indeed, natural systems do work just this way to solve problems and achieve sustainability: specifically, they retain and evolve information about adaptive form. This idea stands in stark contrast to the conventional model of design technology today, which is based upon the mechanical assembly of forms to achieve visual novelty. In that model, quantitative criteria are specified and assessed ahead of time, and a design is engineered to meet those defined program criteria--the square feet of a building, the number of people housed in sanitary conditions, the profit to the developer, the marketing value to the organization, and so on. This program is organized around a rationalized “template” whose elements are segregated and standardized to achieve economies of scale.
Along the way, architects typically perform a specialist aesthetic function: they drape an artistic cloth over this engineered product. In essence, they are product designers, adding a kind of marketing package. If they do their jobs especially well, they may even give it the visual excitement and allure of a fine art, or at least the mystique of a great and mysterious creative design process. But regardless of the imaginative garb, at heart is a “product”--the output of this linear technology, pre-defined and pre-limited, commodified and marketed.
All this works surprisingly well, up to a point. This is the design theory rooted in Scientific Modernism--reflecting a belief that we can use linear engineering methods to rationally create built environments that are orderly and clean. This technology has powered the world for over a century. But this technology is failing us. Ironically, science itself has long since moved on. We now understand pretty clearly that the legacy of this linear approach is a series of disastrous, unintended consequences, compounding with each successive project: failures in the social environment, the ecological environment and, now, the economic system that governs the sustainability of our resources.
We are generally aware that the old paradigm must give way to something more life-like--more able to create resilience and sustainability, and more able to serve the real needs of human beings. We understand that we must move beyond the old “Ponzi Scheme” models of depletion economics--leaving tremendous irresolvable problems to our grandchildren--and find a more regenerative kind of technology, and a more sustainable kind of settlement pattern, to counter the unfolding global disaster of modern industrial development. And yet, there is confusion about where to head, and where deep reforms must be made.
For environmental designers, we suggest, the core challenge is this: is it enough just to festoon our designs with sustainability gadgets and magical artistic incantations, when the designs themselves are still producing the same old failing linear results? Must we not transform the very act of design, to gain this deeper and more poetic quality--not simply a commodified expression of abstract art, applied as a veneer, but as a natural emergent solution to real human and ecological needs? This, in the end, is Alexander’s challenge to modern technology, and to architects specifically. To be sure, some establishment architects resent this challenge. They are understandably comfortable with the status quo--with their incomes and privileges, with the undeniably pleasurable aesthetic adventures that free them of deeper responsibilities, and with the exciting private culture of design that they can share with the relatively small world of connoisseurs and aficionados.
Some very influential academicians and practitioners have shown that they will fight hard to keep the old Modernist status quo (in its endless Rococo variations) entrenched in architecture schools, and in the circles of connoisseurs and critics. Meanwhile Rome burns. The rest of humanity awaits, and desperately needs, widespread implementation of a more effective, humane and sustainable design technology. As the software engineers have begun to demonstrate, such a technology is available, only awaiting adoption by a less complicitous, less fashion-bewitched, more radical generation of architects. As they arrive on the scene, they will find they have many friends and collaborators outside the parochial product design world of the old architecture.
Michael Mehaffy is an urbanist and critical thinker in complexity and the built environment. He is a practicing planner and builder, and is known for his many projects as well as his writings. He has been a close associate of the architect and software pioneer Christopher Alexander. Currently he is a Sir David Anderson Fellow at the University of Strathclyde in Glasgow, a Visiting Faculty Associate at Arizona State University; a Research Associate with the Center for Environmental Structure, Chris Alexander’s research center founded in 1967; and a strategic consultant on international projects, currently in Europe, North America and South America.
Nikos A. Salingaros is a mathematician and polymath known for his work on urban theory, architectural theory, complexity theory, and design philosophy. He has been a close collaborator of the architect and computer software pioneer Christopher Alexander. Salingaros published substantive research on Algebras, Mathematical Physics, Electromagnetic Fields, and Thermonuclear Fusion before turning his attention to Architecture and Urbanism. He still is Professor of Mathematics at the University of Texas at San Antonio and is also on the Architecture faculties of universities in Italy, Mexico, and The Netherlands.
Read more posts from Michael and Nikos here.