Introduction
Christopher Alexander’s Notes on the Synthesis of Form (henceforth Notes) occupies a curious position in the foundations of software architecture. It is often spoken of as important, yet remains far less visible than Alexander’s later work, A Pattern Language.
Most software practitioners who know Alexander’s influence know it through A Pattern Language. This is the text cited explicitly in Design Patterns: Elements of Reusable Object-Oriented Software, in Pattern-Oriented Software Architecture: A System of Patterns, and by Martin Fowler both in talks and in Patterns of Enterprise Application Architecture. By contrast, aside from Richard P. Gabriel’s Patterns of Software, explicit references to Notes in the software literature appear to be rare — though I would be glad to discover otherwise.
Why begin this series with a work the software world barely cites? Because Notes is the intellectual seed from which A Pattern Language grew. One can use A Pattern Language in isolation and gain substantial practical insight. But to fully grasp the reasoning behind Alexander’s patterns — his conception of fit, his method for handling complexity — Notes is essential reading.
This choice is also personal. I am drawn to the philosophical underpinnings of software design, not only its techniques. Beginning here sets the tone for the series: before asking how we design, we should understand why we design in certain ways.
In brief, Notes is Alexander’s manifesto for good architectural design. It addresses: (1) the meaning of “goodness of fit”; (2) the historical design paradigms he terms the self-conscious and the unself-conscious; and (3) a systematic method for achieving good design in the unself-conscious paradigm — the most extensive section of the book. This post will follow that same structure 1 .
Goodness of Fit
Goodness of Fit is Alexander’s way of defining the aim of design in the face of what he calls “insoluble levels of complexity” (p. 3). In his terms, design succeeds when the form (the thing designed) fits harmoniously with the context (the conditions, forces, and requirements acting on it), leaving no significant “misfits.” The more mismatches remain between form and context, the poorer the fit. While Alexander develops this in an architectural setting, the problem is equally acute in software architecture, where even small projects can become unmanageably complex. Many software design paradigms — from John Ousterhout’s pragmatic design philosophy to the Clean Code and SOLID principles — can be read as attempts to manage this same problem: reducing complexity and maintaining fit.
Alexander also issues a warning to architects about avoiding the hard questions that goodness of fit demands. Confronted with the challenge of asking “why” we should prefer one design approach over another, or generally questioning foundational assumptions of the field and design, designers can retreat into the safety of established “styles”:
“Rather than face the responsibility of these difficult questions, designers turned instead to the authority of resurrected ‘styles.’ The architectural decisions made within a style are safe from the nagging difficulty of doubt, for the same reason that decisions are easier to make under tradition and taboo than on one’s own responsibility.” (p. 10)
Whilst aimed at architects, this clearly applies also to software architects and designers of software generally. It's not uncommon to see dogmatic adherence to microservices, Clean Code, or SOLID; using them as fixed styles that avoid deeper reasoning about the specific problem at hand as opposed to useful heuristics to solve a problem.
Briefly recapping, and spelling some key concepts out a bit more clearly:
Form: The thing designed; the end product. For a 'normal' architect, this is the building, the church, the warehouse. For software architecture, if designing a new system to import data from a third party at a faster rate, the form is whatever design implements that capability in the most fitting way for its environment.
Context: The forces, constraints, and requirements shaping the design.
Ensemble: The form and context taken together, considered as a single interdependent whole.
Take the following two direct quotations:
"...when we speak of design, the real object of discussion is not the form alone, but the ensemble comprising the form and its context. Good fit is a desired property of this ensemble which relates to some particular division of the ensemble into form and context."
(p. 16)
"The rightness of form depends, in each of these cases, on the degree to which it fits the rest of the ensemble"
(p. 17)
Context is everything when considering the form; indeed, the form should only ever be created by fully understanding the context, as much as is physically possible. Let's examine this more concretely with a basic example: we are designing a new basket feature in an e-commerce app where users can select an item and it will be saved into this basket where they can subsequently check out. What's the form? In other words, what will the final product look like? Well, that depends entirely on the context.
This context is given by your stakeholders and constraints. As a developer, you will likely want to know about: (1) How long do we have to implement this? (2) How many developers are available to build this feature? (3) What is the current architecture of the app, and what components will we be connecting to? (4) What are our storage requirements, both permanent and temporary? (5) How many concurrent users do we expect? (6) What is our budget for infrastructure costs? This will just be the start of the questions a good designer will ask.
Each contextual constraint shapes the form. A tight two-week deadline with one developer will undoubtedly lead to a simpler solution; a three-month deadline with a full team might justify a sophisticated distributed system with event sourcing and real-time synchronization. This mirrors Alexander's insight that the rightness of any design depends not on abstract principles, but on how well it fits within its specific ensemble of constraints and requirements.
Good fit can also usually only be determined negatively (p22); and achieving good fit should be seen as a negative process of neutralising the incongruities. Alexander justifies by pointing to the fact that we already do this in practice (p24).
To summarise the key takeaways here:
- Form and context taken together are the ensemble.
- The aim of design is to allow form to arise naturally from understanding the context.
- We can create specifications only by defining the absence of negatives, not asserting the positives.
The Self-Conscious and Unself-Conscious Methods
Ways to Make the Unself-Conscious Methods Work
Constructive Diagrams
Programme vs Problem
Explicit vs Vague Criteria
Modelling Vague Criteria in Subsystems
- All quotations with a page number are from Christopher Alexander’s Notes on the Synthesis of Form (Harvard University Press, 1964), unless otherwise stated. ↩