Patterns in software

Software is the one field that took Alexander at his word — and then, by his own assessment, took the wrong half. Three of the industry's load-bearing ideas trace directly to him: design patterns, the wiki, and the iterative instinct at the heart of agile. This page tells that story, and then the more useful one: what the rest of his work — centers, the fifteen properties, generative sequences, the mirror test — has to offer code, APIs and interfaces, which is far more than the GoF catalogue ever carried over.

The lineage: 1987 to the Agile Manifesto

In 1987 Kent Beck and Ward Cunningham, then at Tektronix, ran a small experiment: they wrote five Alexander-style patterns for Smalltalk window design and let users design their own interfaces with them, reporting the result at OOPSLA in “Using Pattern Languages for Object-Oriented Programs.” The idea caught. By 1993 a community (the Hillside Group) had formed around it; in 1994 Gamma, Helm, Johnson and Vlissides published Design Patterns: Elements of Reusable Object-Oriented Software, borrowing Alexander's form — name, problem, forces, solution, consequences — for 23 recurring structures in object-oriented code. The “Gang of Four” book became one of the best-selling and most-cited works in the history of the field, and “pattern” entered the permanent vocabulary of programming.

The second gift was accidental. In 1995 Cunningham needed a way for pattern authors to write, link and revise each other's patterns on the young web, so he built the Portland Pattern Repository's WikiWikiWeb — the first wiki. Its design principles (anyone can edit, links are first-class, structure grows from use rather than from a plan) are Alexander's politics — users as designers, piecemeal growth — implemented in software. Wikipedia is its direct descendant.

The third is a sensibility rather than an artefact. The people who convened at Snowbird in 2001 to write the Agile Manifesto were substantially the pattern people — Beck and Cunningham above all, whose Extreme Programming is saturated with Alexander (Beck has said plainly that XP's practices are an attempt at his ideas). The core agile instinct — grow a system in small, feedback-checked steps that keep it whole at every stage, rather than executing a frozen master plan — is precisely the structure-preserving unfolding of The Nature of Order, arrived at in code while Alexander was still writing it down for buildings.

The 1996 keynote: thanks, but…

Invited to keynote OOPSLA in 1996 (“The Origins of Pattern Theory”), Alexander surveyed what software had done with his work with characteristic double-edged courtesy. The patterns community, he said, had understood the format — but patterns were never the point. They were one piece of a larger project whose aim was living structure, and whose test was whether the made thing improves the life of the people who use it and the world it enters. He asked the room whether they had any equivalent of that aim — whether programs were being judged by anything beyond shipping and cleverness — and suggested that software people, who were rapidly building the environment everyone now lives in, had inherited the moral situation of architects, with no professional tradition of accepting it.

“Please forgive me, I'm going to be very direct and blunt for a horrible second. It could be thought that the technical way in which you currently look at programming is almost as if you were willing to be ‘guns for hire.’” — Christopher Alexander, OOPSLA keynote, San Jose, 1996

What software kept, and what it lost

It is worth being precise about the translation losses, because they mark exactly where the unexploited value still sits:

• Kept the form, lost the language. Alexander's patterns form a connected, ordered whole — a generative sequence in which each pattern creates the context for the next. The GoF catalogue is 23 isolated moves with no sequence and no whole; nothing tells you what order decisions should be made in, which for Alexander was most of the secret.
• Kept the solutions, lost the forces. His patterns are anchored in observed human needs (people drift toward light; waiting is dead time). Software patterns are mostly anchored in implementation convenience — which is why several GoF patterns later came to be seen as workarounds for language limitations rather than invariants.
• Kept the catalogue, lost the test. Alexander offers a criterion — does this step increase the felt life of the whole? — and a discipline for applying it. Software took the vocabulary and kept its old criteria (cleverness, novelty, résumé-fit), which is how “patterns” became, in the 2000s, a byword for over-engineering: pattern-application as a structure-destroying act.
• Kept iteration, lost judgement-of-wholeness. Agile kept the small steps but typically judges them by velocity and ticket burn-down, not by whether the system as a whole has become more coherent — unfolding with the feedback signal unplugged.

Living structure in code

Read with Alexander's full apparatus, a codebase is a system of centers — functions, modules, types, the namespaces between them — and everything he says about buildings transfers with almost no force:

• Site repair (pattern 104): work on the worst part of the codebase, not the part that is pleasant to touch. The refactoring tradition's instinct exactly — and Beck's “for each desired change, make the change easy (warning: this may be hard), then make the easy change” is a two-step structure-preserving transformation.
• Strong centers: a module with a clear center — one type or function that everything else visibly serves — reads effortlessly; a module of fifteen peers reads like a plaza with no middle. APIs likewise: one obvious entry point, helpers gradated around it (gradients, levels of scale).
• Boundaries: the interface layer between modules deserves to be thick and alive — types, validation, adapters, documentation — not a hairline import. Most integration pain is a missing boundary in his sense.
• Roughness: a healthy codebase is locally adapted, not uniformly regular — the slightly irregular module that fits its odd domain is right, and the framework that forces every domain into identical shape is the curtain wall. (Richard Gabriel's Patterns of Software — the best book on Alexander and code — calls the goal habitability: code you can live in and change, as against code that photographs well.)
• Unfolding, not master plans: the rewrite-from-scratch is the structure-destroying transformation par excellence; the strangler-fig migration, branch-by-abstraction and continuous refactoring are unfolding. Generative sequence is the deep reason some orders of feature work feel inevitable and others thrash: each step should create the context the next one needs.
• The mirror test, for engineers: of two designs that both work, ask which one you would rather live inside for five years — not which is cleverer. Teams converge on this question far more than on “which is better engineering.”

The fifteen properties on a screen

The fifteen properties translate to interface and visual design almost one-to-one, and make an unusually concrete review checklist: levels of scale is the type and spacing hierarchy (display → heading → body → caption, with no missing rung); strong centers is the screen's one primary action and the visual field organised to serve it; boundaries are padding, cards and transition states — the onboarding flow is an entrance transition; alternating repetition is list rhythm where the gaps are designed, not residual; positive space is whitespace with deliberate shape; good shape is components that hold up cropped out of context; local symmetries are balanced components inside an asymmetric page; deep interlock is the way content and chrome should grip (sticky headers that carry context, not float over it); contrast is committed visual hierarchy — and accessibility; gradients are progressive disclosure and the intimacy gradient of settings (common → rare → dangerous); roughness is tolerance for content as it really is — long names, empty states — rather than lorem-ipsum perfection; echoes are the design system's family resemblance; the void is the screen's one quiet place — the search page that is mostly empty; simplicity and inner calm is the feature that was removed; not-separateness is the product that fits the user's existing world — imports their data, respects their platform — instead of demanding a new one.

Further reading

• Kent Beck & Ward Cunningham, “Using Pattern Languages for Object-Oriented Programs” (OOPSLA, 1987) — where it started; five patterns, two pages.
• Christopher Alexander, “The Origins of Pattern Theory” (OOPSLA keynote, 1996; printed in IEEE Software, 1999) — the field assessed by its source.
• Richard P. Gabriel, Patterns of Software (1996; free PDF from the author) — habitability, code as habitat, and the most honest reckoning with what Alexander means for programmers.
• Gamma, Helm, Johnson & Vlissides, Design Patterns (1994) — read with vol. 2 of The Nature of Order beside it, as catalogue and missing process respectively.
• The WikiWikiWeb itself — still up; the pattern discussions of the late 1990s are a vivid record of the translation happening.