Reading A Pattern Language

I don’t remember who it was that recommended Robert Martin’s Clean Code to me (a fantastic book, but not discussed in this post), yet what I do remember is that as I was making my way through the foreword, I was struck by a term I hadn’t seen before. The foreword mentioned Christopher Alexander, “father of patterns and pattern languages” who envisions design as a continuous process that is woven into activities as seemingly mundane as “repainting, replacing worn carpets, or upgrading the kitchen sink”, typically thought to be outside of the purview of design. I had expected Clean Code to be about, well, code, and I found it intriguing that we were venturing into design philosophy, and suspected that Christopher Alexander and his mysterious pattern languages could supply the link between these two things. What in the world was a pattern language? Conveniently, it turned out there was a book about it (them?). And this is how I stumbled across A Pattern Language.

Despite not having finished it yet, the book already seems to me to be a work of incredible profundity. I started reading it under the impression that it was a book about architecture, but it quickly became clear that the insights in the book could be extrapolated to just about any discipline.

The idea behind the book is that there are problems that occur when one is designing and building a structure - where a structure could be something understood at a variety of scales - a town, a house, a room. These problems occur consistently and thus admit of a consistent solution. The problems are somewhat abstract, so that the reader can understand how they come to occur in many different contexts, and the solutions abstract also, so they impose as few constraints as possible, yet nevertheless provide a guide as to how the problem can be overcome. The patterns in the title are these problem/solution pairs, but also much, much more than that. An important insight is that the patterns form a language; the smaller, more concrete patterns can be combined to compose larger, more complex ones. This process of combination allows for the organic generation of living, whole, societies. Alexander elucidates the pattern concept thus:

The pattern helps to complete those larger patterns which are “above” it, and is itself completed by those smaller patterns which are “below” it…In short, no pattern is an isolated entity. Each pattern can exist in the world only to the extent that is supported by other patterns: the larger patterns in which it is embedded, the patterns of the same size that surround it, and the smaller patterns which are embedded in it. This is a fundamental view of the world. It says that when you build a thing you cannot merely build that thing in isolation, but must also repair the world around it, and within it, so that the larger world at that one place becomes more coherent, and more whole; and the thing which you make takes its place in the web of nature, as you make it.

In the case of the discipline discussed in this book, it can be said that projects that pertain to architecture have an overarching goal, which is to build a structure. This process is constrained due to the nature of what a structure is - something inhabited by people or used by people for some purpose, and therefore required to be suitable for people. From this stem many other constraints, which can be formulated in different ways, but whose existence cannot be doubted. What does it mean for a structure to be suitable for people? There isn’t a single answer to this question, but there are many answers of variable appropriateness, and these provide a range of constraints of various degrees of rigour that inform the process of building a structure. These constraints are not ad hoc stipulations through which the authors pat themselves on the back, nor do they pertain to the supremely practical considerations of building materials or measurements. Rather, they emerge from human biology and the human condition, and provide a series of mutually supportive scaffolds to accommodate these biological and existential facts about our nature.

As I read the book, I’m finding that it’s the worldview that is the most crucial insight. In addition to the architecture discussed in the book, this worldview allows for the creation of pattern languages in other disciplines. Any creative process will inevitably give rise to problems as our creativity, along with our acquired biases and assumptions, encounters the constraints that are naturally imposed upon us. We share a common human nature, so the creative processes moulded by our imaginations and assumptions will share a degree of similarity by virtue of their originating from human minds. In the same fashion, the constraints of attention, time, memory, and so on, will serve to shape all of our creations in similar ways - after all, the creative processes that generate any project are finite (because we are), and these processes ultimately run on human wetware, which is limited in its own way. Taking into account these similarities, it is also inevitable that the solutions we deploy in an effort to overcome these constraints will have a great deal in common. The finitude of those who consume our creations dictates that information must be organized, literary works must be embedded in a cultural context accessible to the audience, artistic arrangement of colours and sounds must make use of contrasts that are detectable by human perceptual faculties, and so on. These are the kinds of considerations that give rise to the patterns dealt with in the book - the common, universalizable methods used to overcome the constraints of any creative process.

Pattern languages can then be created for any discipline that has developed around a particular kind of creative process. As long as one can define with some clarity:

  • What are some of the main goals that projects within the discipline strive to achieve?
  • What are some of the main constraints that inform those projects? What properties do the projects have to have? What are the properties that the projects cannot have?
  • What are the conflicts that arise when the creative impulse behind the project encounters these constraints?
  • What are some common solutions for resolving these conflicts?
  • How can we describe what these solutions have in common - how can we distill the invariant property, to use Alexander’s term, that these solutions share?

Answering these questions enables the construction of a pattern language for a given discipline - a framework that can be used to generate ‘structures’ of variously granular scale, with which the discipline in question is concerned. This amounts to a system of combinable elements that practitioners of a discipline can use as part of their creative process.

***

There is a lot of variation in how well a given discipline lends itself to the construction of a pattern language. Some disciplines are more ‘private’ than others, and if the projects within it are not a product of collaboration among individuals, perhaps a codified pattern language, to be shared among practitioners, is not really necessary, and won’t ever really be generated. For some forms of creation, the only pattern language that may exist is the one in the creator’s own mind, and nowhere else. Alexander et al. humbly use the indefinite article in the title of their work, to underscore this very point, explaining that a pattern language (at least as introduced in this book) is a point of departure, and that it’s just incidental that the pattern language being discussed is set down in book form. In his introduction, Alexander writes:

Every society which is alive and whole, will have its own unique and distinct pattern language; and…every individual in such a society will have a unique language, shared in part, but which as a totality is unique to the mind of the person who has it.”

Even beyond art, when confronted with the seemingly intractable problems of survival in the world, both physically and mentally, the patterns of our own private natural language are really just the concepts that are overlaid on top of our raw sense perceptions, and through which we see the world. So the pattern language set out in this book is analogous to a natural language in the way that it describes how each individual’s own conceptual network is unique, yet can (or perhaps must) nevertheless be articulated in an intelligible way to others. If this weren’t the case, any potential whatsoever for meaningful communication would be lost (Wittgenstein’s famous ‘beetle in a box’ thought experiment provides an interesting argument for the impossibility of a private language).

***

I had heard of patterns in software architecture before, but as I learn more about software development, I realize why this discipline is a perfect candidate to be understood in terms of pattern languages. Harold Abelson, in his course The Structure and Interpretation of Computer Programs, suggests that computer science deals with idealized components, and that the constraints imposed on large software systems are but the constraints of our own minds. This is especially true today when we have ready access to a text editor, an internet connection, and powerful computing resources. With such forgiving tools, and so much freedom in the creative process of writing software, it becomes even more important to have some kind of organizing principle to manage the complexity we are liable to encounter when piecing together our components and building our structures. This state of affairs gives rise to the ubiquitous notion of a software architecture pattern.

I’m deeply grateful to this book for giving me a way of thinking about the process of creation that I had never encountered before. It’s thrilling to grapple with these abstract conceptual tools, and use them as a way of shaping our own creative processes. But the power of A Pattern Language extends even beyond the conceptual tools it provides. In the context of software development, it’s a refreshing reminder that we do not just work with code, but first and foremost, with people. A lot of the resources I read about software engineering are concerned with system design or its implementation, but don’t often emphasize the extent to which good software depends on efficient collaboration. Of course, this is likely obvious to most serious students, yet I feel it’s important to mention all the same. In the book, significance is attributed not just to teamwork, but also to cultivating this collaborative spirit from the very outset. Without careful stewardship, the structure of a project can deteriorate faster than any future collaboration can repair. Still, one has to start somewhere, and in addressing this point, the authors observe that at the largest scales one cannot exercise complete control over the outcome, but must allow it to be generated organically:

We begin with that part of the language which defines a town or community. These patterns can never be “designed” or “built” in one fell swoop - but patient piece-meal growth, designed in such a way that every individual act is always helping to create or generate these larger global patterns, will, slowly and surely, over the years, make a community that has these global patterns in it.

These penetrating observations, guideposts for both our professional as well as personal lives, are a testament to the authors’ remarkable ability to distill experience garnered over long careers as architects and educators. And it is these observations that make A Pattern Language a truly inspirational work. There is such a prodigious wealth of information contained in it that I knew this was something I would have to explore in depth and keep on my shelf permanently. Written with poignant humility and generosity, this is a strikingly empowering and deeply valuable literary contribution. The authors’ other works still lay ahead of me, and it’s exhilarating to consider that developments have since been built on such a brilliant foundation.



References

Alexander, Christopher. A Pattern Language: Towns, Buildings, Construction. Oxford Univ. Press, 1977.

Martin, Robert Cecil. Clean Code: a Handbook of Agile Software Craftsmanship. Prentice Hall, 2009.