Christopher Alexander was born in Austria. As a toddler his family moved to the UK in 1938, where he grew up. He read Mathematics and Architecture at Cambridge, before going on to receive a Ph.D. in architecture from MIT, and moving to California taking a role as professor of architecture at Berkeley.
Alexander’s first book, Notes on the Synthesis of Form was effectively a publication of his Ph.D. thesis and was said to be required reading for Computer Science researchers in the 60’s and 70’s. The basic premise of the book is that you can cluster forces into mutually entangled sets that provide the place where problem can be solved.
The Timeless Way of Building, is the first volume in the Center for Environmental Structure Series, although A Pattern Language, the second book, was released first in 1977. It was A Pattern Language that influenced the Gang of Four’s Design Patterns book. However, these are not design patterns as described by Alexander (stack overflow discussion).
The Timeless Way of Building walks us through how Alexander reached his idea of patterns. He starts off saying that places have a quality to them which we desire. He tried to name this quality using “alive”, “whole”, “comfortable”, “free”, “exact”, “egoless”, and “eternal”. But in the end decides that there is no name that truly captures this quality that we desire, so settles on “the quality without a name”. However, he then tends to refer to places as being “alive”.
We are told that buildings which have this quality, have a certain character which shows through again and again. These characteristics he describes as patterns and begins to name a few. i.e. Intimacy Gradient, which states that spaces in a building should be sequenced, beginning with the entrance and the most public parts of the building, leading into slightly more private areas, and finally the most private family spaces. This could be a formal sitting room where guests are entertained, leading into a family kitchen where close friends may be invited, and then onto the bedrooms.
The patterns have a well-defined format:
- a name,
- the context where this pattern is applicable,
- a diagram,
- the forces/trade-offs when considering this pattern, and
- a discussion as to why this pattern works.
It is this format of the pattern that we have come to know through the GoF work, and later patterns books, i.e. Fowler’s Patterns of Enterprise Application Architecture or Meszaros’ xUnit Test Patterns.
However, Alexander spoke at the OOPSLA 96 conference (YouTube video), where he pointed out that within our industry we have misunderstood patterns saying:
When I look at the object-oriented work on patterns that I’ve seen, I see the format of a pattern (context, problem, solution, and so forth). It is a nice and useful format. It allows you to write down good ideas about software design in a way that can be discussed, shared, modified, and so forth. So, it is a really useful vehicle of communication. And, I think that insofar as patterns have become useful tools in the design of software, it helps the task of programming in that way. It is a nice, neat format and that is fine. However, that is not all that pattern languages are supposed to do.
Jim Coplien has been out in the community trying to explain what patterns are supposed to be, and as the stack overflow post points out that 10 years after the Design Patterns book was published, Richard Helm admitted that he finally understood the generative nature of patterns.
As mentioned, Alexander sees more in patterns. He explains how patterns are built one on top of another in their own language, likening it to a language where words combine following a grammar to form sentences, patterns have their own language. Starting with the larger patterns we follow an order into the smaller patterns, which in turn are made up of smaller patterns. This then defines a whole, where the larger patterns are incomplete without the smaller ones, and the smaller make no sense without the context of the larger system. Together they all need to balance out.
Finally, after building up where patterns come from, what patterns are and how they interact, Alexander then walks us through examples designing a cottage and then planning a hospital. He shows us that not all the patterns make sense in each context, and that we need to follow the structure and order of the language.
I love that he talks about buildings needing to be egoless, not about the people designing but about those that will use the building day after day. Although describing the architecture of where people live, from cities down to a window seat, it’s amazing how the ideas can fit to other situations such as computer systems. We need to remember this in building our systems. It’s not about the latest, coolest tech. It’s not about the most beautiful code, incorporating every design pattern, it’s about making something that the users will love day after day, and look forward to using.