This book isn't life changing so much as it expresses clearly and beautifully things which I know deep inside. And yet, since what is being described is itself so hard to describe, the truths of this book are sometimes more felt than explicitly learned.

On the surface, this book is about how to develop pattern languages and use them to guide building physical places which live. The patterns are all from the domain of architecture. Some elements, such as how to go about the processes of detailed design or building are deeply impractical in a culture where, for better and for worse, much of what it takes to build buildings has been professionalized. (That said, as a metaphor for software creation, which does depend on taking common components and contextualizing them, they are more applicable.)

However, none of that matters because what you really take away is the deeper sense of what it means for a system to be alive, whole, comfortable, free, exact, egoless, eternal — for it to have the quality without a name. The quality without a name is that deeply felt yet hard to describe sense of rightness that things sometimes have. It can be thought of as a sense of dynamic equilibrium where all forces are aligned and tensions resolved. Yet even that is a deceptive description because the forces in play are always changing and so while particular solution may embody the quality without a name for moment, for a system to have this quality, it must be always adapting.

Because there is so much great material in this book, I'll just highlight some of the ideas I loved best.

The world is made up of relationships, called patterns. These patterns arise from the events which happen repeatedly in a space. Patterns which help resolve the tensions that arise from these events are alive. Those patterns which create or increase tensions eventually make a space dead. Dead patterns cannot be isolated. They eventually leak out and contaminate the whole system, so it is important to try to resolve them, not just hide them. Living patterns reinforce each other.

Patterns together form a pattern language. A pattern language is made of patterns which relate to each other in a certain way: a pattern depends on the components which are needed to make it whole. In computer science terms, patterns form a directed acyclic graph. We each have our own pattern language which is built from the forces we've had to deal with in our lives. Yet our pattern languages are also shared. We learn patterns from each other and our own patterns evolve in response to what we learn. It is because these languages are largely shared that the application of a pattern language can lead to a common character over a larger set of design decisions.

Design works best when it is holistic. At each step of the design process, design should apply differentiation on a whole. Details should not be designed in isolation, without any concern for their context. Rather, the context should be defined to form a whole, then the parts within that refined to form a more detailed whole, and so on until a design is complete down to the details. If a design is whole at every step of the way, it minimizes the chance that a later detail will derail the big picture design. This process of refinement depends on having a properly structured order for design. In a pattern language, that is captured in the hierarchical relationship between patterns.

A shared pattern language can help a design to be coherent when applied to design decisions made in a community. Nested groups should be responsible for design, where the group that uses a pattern at a certain scale is responsible for designing their own solution. However, they are also responsible for making sure their solution fits coherently with the larger patterns it is encompassed in. The larger groups which the smaller groups are a part of are responsible for instantiating those larger patterns. When a pattern language is shared across a community, this process of delegating design to the smallest applicable group can create a coherent whole even while many independent decisions are being made.

All that just scratches the surface. This book has so much to offer, and I look forward to reading it again. ( )

I came to Pattern Language with an eye toward theory and meaning, more than a specific architectural interest. How do wholes and parts relate? What ramifications follow from specific choices at one level, for preferences or objectives at another level? Primed with readings in Batesonian cybernetics, I was curious what Alexander would bring to the table.

Alexander found in bespoke building (artisanal craft) a distinction perhaps unexpected. It's not about higher or lower quality of custom-built pieces, in fact he implies at various points that modular / prefabricated pieces will be more precise and consistent in their construction. However, artisanal & modular approaches are very different, and yield distinct results at the scale of wholes, and when pieces interface. Alexander's "quality that cannot be named" or "timeless way" is essentially about coherence or integrity. He claims modular building often won't yield coherent results simply because the approach ignores the specifics of site and / or the remainder of the edifice in which one is building.

An example makes this clear. Pre-hung windows and doors are available in pre-set dimensions. One chooses where in the room they go, but precise placement is limited by the pre-set options. If the builder wants to set a window so as to frame a lake in the distance, but not intrude on either a radiator in the room or the branches of an oak tree just outside the house, nothing can be done but hope the dimensions work out. It's likely available windows will be too large or too small for the purpose, and the objective can only be partially achieved. The issue can be minimised with greater choice in standard sizes, but the inherent obstacle cannot be avoided. Bespoke windows allow the builder to determine precisely where the window should appear so as to balance the vista with the room's interior layout.

Characterised generally: modular building assumes a Cartesian grid, maps the specific site and structure upon that grid, and construction is undertaken in a modular fashion from prefabricated (and predefined) materials. That grid can be finer or grosser in its precision, but it remains a grid. Artisanal building assumes a scale specific to the project, fits the structure to the site, and construction is undertaken in a relational fashion: that is, driven by dynamic between pieces and wholes at varying scales. Alexander attempts to marshall the efficiencies and wisdom of modular design by applying patterns to typical situations. These patterns, at root, identify dynamics one can expect to recur, and suggests useful considerations ("rules of thumb") for solving these dynamics in specific instances.

In a discussion on coding design, a project manager noted the Agile framework exists predominantly as an abstract, with little evidence of success at scale. A major challenge is how to code for large projects, when detailed coding for specific modules and subroutines are developed weeks or months after the full project was mapped out as a whole. When interactions between modules encounter obstacles or conflict, the relevant teams are often deployed elsewhere and can't hash out specifics. I wonder if a Pattern Language approach would be fruitful in avoiding such problems. ( )

Excelente libro de consulta permanente. ( )

I read this as an introduction to Alexander's other books. The same sentiments apply.

This is a very easy to read book. It explains the philosophy of pattern based design much better than many later books have managed. Reading it it is obvious why so many Design and Software gurus consider Alexander as a big influence. ( )

one should not set most of a book in italics!