Introduction

This book is for curious software developers of all types. It doesn’t matter which language you use and the industry you work in is irrelevant; what does matter is your interest in why things are the way they are. You will find much more than object-oriented design patterns here as the problem we face is far broader.

This book is for developers who have heard of, used, or even read up on design patterns but think something is missing or needs correcting. It is also for those who wish to know why this can still be the case. Furthermore, it is for those individuals who love design patterns and want to know how to extend their benefits. This book is for developers with little to no experience in design patterns who wish to avoid their pitfalls, and it can benefit anyone who has worked with patterns for a while but was surprised when their purported values did not emerge. It is for those who like the design on the cover and think it would look nice on their bookshelf.

In these pages, I hope you will find practical tips and useful takeaways, but this is not a how-to manual. Instead, think of this as a book that explains the principles you can use in the following ways:

• To build a toolkit of techniques to dissect existing patterns
• To learn how you can better repair broken things when you see them
• To uncover ways to correctly identify whether they are broken in the first place.

In short, if you have opinions on design patterns, this book can help you justify them. If you don’t, you might just begin to develop some. Additionally, as a bonus, you will discover how to get the most out of them, regardless of their flaws.

As the story unfolds, the foremost players will be an architect, a small group of software developers, a movement populated by hundreds of developers, and the way in which the world reinforces our actions.

The architect

Christopher Alexander was the architect. He was the central character for the initial discovery of patterns and set the course of pattern history. Although he wasn’t a software developer by any means, he was fascinated by the possibilities presented by developing software using a pattern-language approach. His book A Pattern Language[APL77] became famous among software developers and was the basis for the formation of design patterns in software. However, his story takes its first and most consequential step with the much earlier book Notes on the Synthesis of Form[Notes64], which was written back in 1964 when he was still an academic.

The software developers

A small group of software developers became known as the Gang of Four, often abbreviated to the GoF. Together, in 1994, Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides produced an incredibly successful book called Design Patterns: Elements of Reusable Object-Oriented Software[GoF94], which detailed 23 software design patterns for object-oriented programmers to learn and use. This best-selling work is often called the ‘GoF book’, and that is how I shall refer to it throughout this work.

The movement

The software-design-patterns movement was real and still exists to this day, but it is now far more low-key. At its height, hundreds of developers contributed to it and spread the word to anyone who would listen. In addition, the movement rippled out into other areas of development, such as education, and organisational change. As the hype receded, only a few remained faithful to the broader pattern movement.

The world

The last component of the story is the world itself and how natural laws of emergent behaviour clashed with many of the expectations and needs of those involved. This final element—the emergent behaviour of complex systems—brings us back to the start. Christopher Alexander’s first work sought to tame complexity in intensely interconnected projects and guide the emergent properties of larger systems to positive conclusions.

Our journey

During this voyage, I must reference patterns from software development and physical architecture. The majority of the physical architecture patterns identified by Christopher Alexander and his colleagues are from the book A Pattern Language. As they are numbered in that book, I will reference them as follows: 202 Built-in Seats. The software design patterns in the GoF book do not have numbers, so I will reference them in the following manner: Strategy. Not to spoil the surprise, but other software design patterns will also be referenced in the same way. At the end of the book, there are summaries of most of the patterns that are mentioned to help those less familiar with the subject; however, they are my summations, so you may still want to obtain a copy of each book to fully comprehend the patterns held within.

Before we begin the journey, we should take a look at the road map. In the rest of this introduction, I intend to highlight the kinds of questions that I later attempt to answer—this is so that you know where we’re going. The terrain will get a little rough at times—and there are no well-worn tracks in many places; unfortunately, this means that it will be necessary to explain some of the historical and theoretical elements of the topic along the way. I won’t try to convince you of anything nor attempt to directly answer any questions in the remainder of this introduction; only clarify what I intend to address by the end of the book.

However, most software engineers (and leading search engines) get this figure wrong, as there are many more. If you’re in the camp that thought there was a higher number, you might be thinking about the Pattern-Oriented Software Architecture series of books¹, the Pattern Languages of Program Design(PLoPD) series², or other books like Game Programming Patterns[GPP11]. In fact, there are many domain-specific software design pattern books, so maybe you were thinking about something more modern, such as Node.js Design Patterns[NODEJS16], the patterns from Cloud Native Transformation[CNT19], or Machine Learning Design Patterns[MLDP20].

Nevertheless, these books only cover a few hundred examples. Unless your answer was in the thousands, you were still way off. In fact, you would have been conservative in your estimate in the year 2000; if you only include the list of published patterns, the number already exceeded a thousand³ as is evidenced in those collected in The Pattern Almanac 2000[Almanac00], a book published to help track the currently recognised and widely used patterns in software development.

This raises another issue. The almanac only accounted for the patterns discovered and published in and around software development. Many people forget that other areas are equally important to software developers:

• Learning and teaching patterns.
• Patterns of people management and organisations.
• Patterns of bringing about change.

The belief that patterns are limited to software engineering, restricted solely to the domain of object-oriented design, and constrained to patterns of implementation, is an incredibly narrow viewpoint. It would be like claiming you know how to cook when your culinary expertise only stretches to five different ways to make eggs on toast.

So why do we collectively believe there are only 22 or 23 design patterns for software when there are actually so many others out there? Moreover, if so many patterns exist and more are being found all the time, where are they? I will answer these questions and also explain how this state of affairs was somewhat inevitable.

There was a place—the original wiki—which kept track of patterns and the conversations around them. If you have heard of this site, which is known as the Portland Pattern Repository, you may also know that it hasn’t been updated in some time. Why is this the case? There is also the Hillside Group, which maintains a website with many (often dead) links, but they’re not as famous as the GoF book[GoF94]. Why does an exhaustive pattern catalogue for everyone to use not exist?

While a definitive answer explaining why this didn’t happen in the past would be impossible to provide, I will reveal the many forces at play that continue to make it an unlikely event. You will learn how those forces affect the established software development practices but also those processes and methodologies only recently adopted. In addition, you will learn how physical architecture and building development are similarly affected.

Language

If you look at any modern and reasonably sized piece of software, you will surely come across something with the word factory in the name. You might also find a few singletons in the code. The larger the codebase, the more likely it is that you will see recognisable object-oriented design patterns. You may even note a query_decorator, a list_iterator, a status_observer, and possibly even a page_builder or two. These pattern names have become thoroughly entrenched in our software development language.

Though not as widely studied these days, design patterns are regularly used by people who have yet to see a copy of the GoF book[GoF94]. The names of these patterns are baked into tutorials, how-to guides, and example code, all of which people copy and paste into their projects.

Design patterns first appeared in Notes on the Synthesis of Form[Notes64] as a byproduct of Christopher Alexander’s efforts to find a way to reduce the complexity of large-scale building projects. We will go into the details later, but a feature he saw in them at the time was how they formed a language. This sense of it being a language was only made clear in the books he published after his time in academia, A Pattern Language[APL77] and The Timeless Way of Building[TTWoB79]. Software design pattern terms becoming so ubi¬quitous affirms this conclusion.

However, there is a downside to the language-like qualities of patterns; they become less useful in the long run. The benefits of structure and communicability also have their pitfalls, as they lead to a loss of essence when referred to by an arbitrary handle.

As an example of the weakness of words, what does the word ‘literally’ mean to people now? In the past, it used to mean ‘real’ and ‘actual’, not the imprecise term it has now become. Additionally, what does ‘done’ mean to the people you work with on different projects? Language evolves. Sarcasm aside, words and their meanings are relative to the environment and the participants in that environment. We need to recognise that definitions are not eternal and immobile—but rather cultural and flexible.

The books published in the 1990s were full of recognised patterns—and pattern authors gave names to each of them. The names stuck around, but our understanding of what those patterns mean has drifted. When we copy patterns without completely understanding them, their meaning mutates. If we copy a visitor pattern from an implementation that walks a structure of composite objects, but we fail to see the details of the typed callbacks, the pattern word will now mean something else. We can be forgiven this as even the GoF referred to the Visitor as the ‘Walker’ before the book was published¹. So, what do all those GoF names mean now?

Beyond the individual names of patterns, nowadays we regularly exchange the term design pattern with technique or UX design-systems. Some authors will add ‘design patterns’ to the title of a book or webpage to instil a sense of validity to the content delivered. It is intensely dissatisfying to observe how anything that indicates a property will inevitably be mimicked and ruined; from black-and-yellow striped but non-threatening insects to five-star review bots. However, why is this dilution of meaning not seen as a problem by those involved in the patterns movement? Worse still, when it is recognised as a problem, why is it seen as somehow unavoidable?

Aside from co-opting the term, UX design patterns exhibit another problem. Even though some people complain that the GoF patterns are idiomatic, UX patterns suffer from the same flaw to a much greater extent. I explain in more detail later what idiomatic means for patterns, but compared to authentic pattern forms, idioms are less powerful, less adaptable, and often unfalsifiable.

Indeed, UX patterns don’t fit into the original definition by Christopher Alexander, but does this matter? Are idioms just as useful in practice? Given how the usage of the term has changed, what is the value in trying to fix anything about design patterns if they don’t exist anymore, except in the form of a book and some recurring names?

I will answer these questions and explore how to regain some of the benefits of patterns without requiring the whole system to be overhauled.

The GoF book

There is also the question of the content and form of the GoF book[GoF94]. First published in 1994, it’s stood the test of time for a work on computer programming. No book other than Clean Code[CC08] seems to have sold nearly as many copies while also still being regularly recommended to new generations of interns and graduates. However, there’s never been an update. Even a later book on the same subject, Head-First Design Patterns[HFDP04], has a second edition. So, the first question must be, is there anything wrong with that? Are design patterns eternal, meaning the book does not need an update?¹ Given the number of patterns, this cannot be right, can it? Therefore, we’re left with the questions: what needs updating, and what should an update look like?

There is also the question of why other books on patterns are not in the top ten of best-seller lists for software design and architecture. I had to get down into the 20s before I found another title at the time of writing. In the lists I saw, which offered rankings² in accordance with estimated sales figures, Game Programming Patterns[GPP11] was only at position 27. If there’s such a glut of patterns and books on patterns, how come they sell in significantly different quantities? Did the GoF book’s success drown out other design pattern sources?

Some people have asked whether the GoF patterns are design patterns at all. In fact, more experienced people than me have called them out as idioms—while some individuals have stated the GoF’s patterns are not found in actual use anywhere³. Others claim their use only began because of the paper and the book—turning them into a kind of self-fulfilling prophecy. Why do people think the book’s patterns aren’t actually patterns? If this is true, what are they then? And what would an actual pattern look like?

Finally, there’s the question of form. There are some concerns regarding the way the patterns are structured in the book; some of them did not make complete or obvious sense when contorted into this mould, making them less practical than they could have been. The work also observes that there are significant differences⁴ to Christopher Alexander’s patterns and does not strictly adhere to the principles of his pattern language. This begs the following questions: why do some people think the movement could have been hurt by setting a theme and structure for patterns? What harm did this literary structure do to the power of patterns as both a device and a movement?

Systems theory

Central to the history of design patterns was a drive to tame the complexity inherent in architecture, both in terms of physical construction and software. Both forms of development deal with sequences of constructive actions with continuously interacting elements. Interactions between elements, which in turn create emergent behaviour, are what systems theory is all about. So, given how linked together they are, why do we fail to teach systems theory alongside design patterns?

We can use systems theory to analyse questions regarding the larger systems at play in the design pattern space, not only in terms of the patterns themselves but also the development of the theory of patterns. Moreover, we can examine the systemic problems caused by the current processes for finding, publishing and their eventual use. There were certain forces at play that drove the adoption of patterns, yet others have diverted them toward a different form. The pattern movement changed over time, and systems theory helps to explain and predict some of the otherwise unexpected outcomes.

In later works by Christopher Alexander¹, it becomes apparent that systems of feedback between larger social entities—such as the pattern movement, the software development industry, and the construction industry—led to some far-reaching consequences. These outcomes range from the mundane, including mass selling-out, to the unnerving reality of corruption, bribery, and death threats. Systems theory will help us to frame these events so that we can see them coming before they arrive and avoid similar problems in the future.

Unfulfilled potential

Design patterns seemed like a fantastic thing when they first became popular. Their promise of improved code reusability was—and still is—vital to many people. However, we need to know why that potential was not realised. Given how many patterns there are, with all their combined, compiled wisdom, why were they so ineffective as a form of knowledge transfer? This point is not debatable; as they stand, they are ineffective. The lacklustre level of adoption of any but the GoF patterns in mainstream development practices is a clearer testament to the inefficacy of the movement than any statement I could make.

Large-scale, complex software requires considerable effort to get right. The work of Christopher Alexander was all about managing the complexity of a different domain. What happened to that aspect of design patterns during the concept’s infiltration into software design patterns? Why haven’t they helped to tame the complexity? Was the initial response of the software industry neglectful of his work? What can we do to put ourselves back on track? Do we need to go back further and start again? In other words, should we walk the same path as he did to derive our own truer, more fitting form of patterns for software development?

Tracing the history of how the design pattern movement affected buildings and architecture reveals another parallel with software development. When and where the patterns processes were allowed to run their course, you can see how they created significantly better final results than the alternative—the default approach of contracts and paper design. However, the determination of what is better is a value judgement from a particular perspective. According to systems theory, the world stood in the way of what was locally good because the system above viewed Christopher Alexander’s work through a different lens—a lens of power.

That skewed interpretation remains as much alive in software design pattern related activities as it does with regard the physical building space. Inevitably, this leads to similar obstructions and corruptions of the process. Is something actively stopping design patterns from achieving their potential? If so, can we do anything about it?

Where next?

I hope I have successfully whetted your appetite with these questions or, at the very least, helped you decide whether this book is for you. Either way, I have outlined the premise to be explored in these pages. My research is incomplete, and I wonder if it will ever end, as this topic is significantly broader than I initially believed. I continue to dig further as I write this first edition and will likely produce a follow-up edition a decade or so from now. If not, I hope this book will explain why I, like the GoF, never got around to it.

What I have learnt has changed my mind multiple times. I used to be a staunch design pattern sceptic. I believed patterns to be useless cargo-cult content. However, I now find them fascinating and useful but ultimately unfinished. There is much work to be done to get them to where they could be, so I lay out the measures that need to be taken. This is not a call to arms but rather a projection of what the future may hold if I, or others, engage in the necessary work. There is promise there, but no promises, I’m afraid.

Now, we must start at the beginning. A full description of the origin of the form is absent from so much of the literature on design patterns. However, as is so often the case, history holds the key to understanding. It will help unlock their potential and reveal the reasons why things went wrong for design patterns in the way they did.

The Link to Agile

To fully understand design patterns, it’s useful to trace how they evolved through the different domains of their existence and how each domain affected and was affected by design patterns. However, you’re not here for a history lesson. You’re a software developer who wants to know the relevant details with some fundamentals to back up the claims. This is why we will take a shortcut to the point where the most striking similarities between the two design patterns movements—in physical architecture and software development—seem to have materialised.

Agile, as it is understood these days, is a non-process where software is developed and deployed according to the Agile Manifesto ¹[AM01]. The core values can be stated as follows: preferring to take responsibility; delivering useful things directly to the end user; and actively seeking out and adjusting the processes based on new information. These ideals of product design and delivery are evident to us now. However, they were also obvious a couple of hundred years ago—so something clearly went wrong along the way.

At the same time as the design patterns movement in software, other changes were brewing. The concepts at the core of Scrum can be traced back through published works on the Portland Pattern Repository or found in Pattern Languages of Program Design[PLoPD95] (from now on referred to as PLoPD) under the heading ‘Episodes’. Yet they go back even further than that. Most of the salient features of Scrum’s developer empowerment appear in Episodes, and many of the features of the Agile Manifesto can be traced back to elements that were present in those and even earlier works.

It’s not that the Agile principles came from design patterns, nor did design patterns come from Agile, but they both appear to stem from the mood of the times. Both emerged from similar feelings that there had to be a better way to develop software. A backlash formed from the notion that we could increase quality by moving decision-making closer to the place where the effect of those actions could be observed.

Christopher Alexander had shown the value of looking to the recipient and user of the product as a guiding force for decision-making; in some cases, even a worker on the building site would be deeply involved. Agile development is an attempt to bring the customer closer, even going as far as to suggest including them in live tests during development. Alexander’s work on the processes of using patterns to help guide production mirrored many aspects of the worker empowerment found in Episodes and Scrum.

The Agile Manifesto, extreme programming², design patterns, Scrum³, and even to some extent, the notion of User Experience⁴, all appear to originate from the same period where people were bouncing related ideas around and communicating with fresh and wide-open eyes at a time of client-centred thought. Although these ideas did not come directly from Christopher Alexander, and many had their origins before this time⁵, there was nevertheless a sharp change in their uptake around this period. This was the 1990s. Back then, adults were witnessing the growth of computing across the world and the rise of the internet. It was the early days of success in technology outside of office usage. These were the days of Nintendo and Sony vying for the top spot in videogames consoles and, at times, innovation was valued over consistency. It could simply be that the information was more readily available. Personally, I think it’s an interesting connection, even if it’s just a coincidence.

Complexity

For anyone reading the GoF book[GoF94], the abridged history and reference to the originator of the term ‘design pattern’ might be misleading. The information on Christopher Alexander can be found early on in the book but is quite limited in scope. When I first read this work, I imagined that he was some revered figure from an era before my grandparents were born, but the real story is much stranger and more intriguing.

Christopher Alexander was not some historical figure who lived during the height of the old British Empire. Instead, he was a modern architect working at the time of the rise of the software-design-patterns movement. However, he would have almost certainly refuted the claim that he was a modern architect, as there are many preconceptions associated with the term.

Some individuals, including myself, suggest he was a post-modernist because he understood modern architecture more deeply than most modern architects ever did. This deep understanding led to his disillusionment with the architectural institution as a whole[Grabow83], and simultaneously led to him being praised and revered for a generation as a ground-breaking architect with a vision for a new era of architectural methodologies.

When most people think of modern architecture, they think of glass and steel buildings rising in the sky. They picture cubes and off-angle constructions. They conjure images of brutalist buildings built with cutting-edge mechanical engineering techniques. All these things are modern architecture, but they are not modern methodologies. This realisation by Christopher Alexander precipitated his journey into patterns and beyond. He saw the modern way as stagnant and realised it was stymied by complexity.

The mainstream understanding of building architecture was—and still is—that an architect must first produce a design, and only then can it be built. The more elaborate and complicated the design, the better the architect must be in order for the project to succeed. If a large design were commissioned, the project would need an architect who could handle the necessary thinking to produce it. They would need to spend much time in deep thought, imagining a new building from nothing and then drawing out the design. A first draft is always thought to be flawed, and so the process was geared towards assuming this was a truism and allow further iterations. Others would review it and help the architect revise the plan where necessary, but it was always a singular vision.

As any project grows, the number of interconnected pieces multiply. A single human mind cannot consider all of the effects of changing one or two small parts. Because of this, modern architecture often relies on modular parts or last-minute additions to fix impossible stresses. Modern modular construction moves the decision-making and problem-solving processes away from the construction site and back to a paper plan, trivialising the problem into an abstract form. Instead of solving a wiring or glazing issue for a specific house, modern methods use modular pieces to resolve the more general puzzle of glazing or wiring for the average house. There is a problem with this though: I don’t know anyone who is precisely average.

Such forced inattention to local details and deviations inspired Christopher Alexander to write his original work, Notes on the Synthesis of Form[Notes64]. In it, he describes a way to attend to these common problems of complexity using a new way of working he developed to resolve the inevitable complications of large modern projects. It’s not overstating things to say that Christopher Alexander was the first person in centuries to develop a new approach to architecture.

From the start, Alexander’s work revolved around resolving the problem of dealing with complexity in our world. Since we had passed the point where traditional architectural methods—which happily adapted to changing needs at a local scale—could no longer keep up with our new technologies, we could not go back. Furthermore, because modern architectural methods—which could support ever-changing technologies—could not address critical problems of complex environmental constraints, we needed something also surpassing them. Notes on the Synthesis of Form promised to provide a process to reconcile this, but it was only the first step in a grander sequence of discoveries.

Christopher Alexander refined his methods over the course of decades. During the period of the software design-patterns movement, his work on architectural patterns had already stabilised. However, he was then in a phase where he was working to refine even more fundamental properties of forms and processes of change. We rarely see references to this later phase within software development literature, but its absence may provide some insights into why the patterns movement ended up the way it has.

The way Christopher Alexander worked

Christopher Alexander’s processes differed from those of the prevailing builders and architects at the time[TOE75]. Indeed, many aspects of his work were similar to the principles espoused in the Agile Manifesto[AM01]. They were iterative approaches, which demanded taking small steps and reviewing regularly. They employed mock-ups rather than extensive up-front planning and documentation, used prototypes to prove an idea and elicit otherwise missing requirements, and required working with the client directly[NoO3-05].

However, his team also used other processes that were less in keeping with what we consider agile software development to be. They would use numerical methods¹ to solve things, performing experiments through simulation. They would use new materials in novel ways², offering some of the benefits of traditional materials but without their limitations. Additionally, they worked to a limited budget and kept track of what was possible³, rather than revising costs and requesting additional funding. In a critical departure from agile software development principles, they were unable to provide a constantly deliverable product as they did not have multiple working versions from which a preferred solution could be selected. Half done for them was not done at all.

Christopher Alexander built processes that facilitated faster feedback and provided the freedom to do the best thing to get that feedback while balancing it against a budget. Remember, this was the 1970s, long before DevOps⁴ turned up. Traditional builders had limited time and money for construction, and the same is true of any modern architectural project. In that respect, his process was no different. The difference was his commitment to producing something viable within that budget rather than pushing to have the budget increased. When the team needed to add something, they took something else away—even when this trade was thrust upon them[Battle12].

Christopher Alexander’s developments had the capacity for adjustment built in; nothing relied on everything else being just so before it was usable. However, this called for a different way of working; elements needed to be adaptable. This was why he sought out new materials. For him, it was essential to have the opportunity to make adjustments on site in response to last-minute revelations⁵. These revelations were the unpredictable issues brought to his attention by the process of construction, not just during, but by the feedback from the act of constructing—things no-one could have anticipated before beginning the work.

Some agile development methodologies suggest a similar approach. Deploying working code to clients early to get feedback is similar to constructing within a budget so that the client gets something, even if everything else goes wrong. Working to an overall budget and realigning as the project progresses draws parallels with the principles of working with adaptable materials and building flexibility into the process. Prototypes and spikes⁶ are manifestations of the cardboard cut-out approach to getting on-site feedback. Simulations of architecture mirror the making of walking skeletons in code, as both of them prove that the overall structure works as expected.

Innovation

Christopher Alexander and his team were known for inventing new processes to get things done that were realised just in time to meet their needs⁷. Unlike other architects, he was hands-on during his building projects, often finding new ways to achieve his goals while keeping costs low. The whole team worked like this, constantly taking into consideration all of the available information about the construction site. The availability of labour, tools, and materials guided them to discover new processes within easy reach, often undocumented or unique, but always appropriate.

Many examples exist throughout his printed works illustrating the way in which Alexander’s team developed solutions for specific contexts. In The Nature of Order, Book 3[NoO3-05], there is a collection under the title The search for new materials (starting on page 518) in which he describes many such instances as well as some of his reservations. One complaint relates to renewable materials having lost some of their value as they have been made less adaptable to their environment by the processes of others. Later, he gives credit to the developers of aerated concrete blocks⁸, which might seem surprising. But for him, the key was that they were adjustable and conformed to the builder’s needs as well as wood or clay might.

Alexander paid attention to the environment right from his first project⁹. In 1961, while living in Gujarat, he developed a way to build a roof for a new school. Local resources were scarce. There was no wood to speak of and almost no access to transport for bringing materials in; however, pot-shaped guna tiles were readily available. His approach involved using stacks of these tiles, which made it possible to place arches in parallel lines and produce a dome. Supporting material is not free, and the self-supporting nature of the arches overcame that requirement. The outward thrust from the arches would have been a problem, but he found a solution in the nearby cotton fields; the dome was tied using the plentiful supply of tensile steel straps, which were originally intended for tying cotton bales. The whole process was suited to the materials that were available.

—Christopher Alexander, The Center for Environmental Structure, The Nature of Order, Book 3[NoO3-05], p. 527.

When I researched his history, I was shocked to learn that Christopher Alexander used all the available materials rather than just traditional ones. I had assumed he would have used more well-proven materials as they had easier-to-understand properties. On the contrary, he developed innovative ways of working with new materials as a regular part of his processes. This use of modern materials in novel ways meant that he could hardly be called a traditionalist.

He developed many new ways to work with concrete, challenging brutalist architecture’s dull and repetitive results[NoO3-05]. He worked with high-pressure water jets[NoO3-05], which were typically used to cut steel, to cut stone for experiments relating to decorative layout. And then there were the revelations about traditional materials, such as the way in which stout wooden beams, though costly up front, would be more environmentally friendly and cost-effective than the smaller stud forms simply due to the many hundreds of years for which the buildings might stand[NoO3-05].

Locally, but remote

Working at the site was a common requirement for Christopher Alexander, but one project¹⁰ proved he could even overcome that constraint when necessary. Although his team was not asked to complete the project, he still solved the problem of working remotely. The contract conditions included a requirement to lay all 8000m² of flooring during a two-month window during the construction of a new concert hall in Athens.

Alexander needed access to a view of the floor and the actual materials, not merely an image of them, so his team rented out a warehouse sufficiently large to house sections of the final product. They cut tiles and placed them on fibreglass mats. When the design finally looked right, viewed as they would appear in their ultimate resting place, they glued them down. The completed mats were also cuttable, meaning they could adapt to any deviations and match unexpected errors in the borders when they arrived in Athens. The process proved that as long as you understand your goals (to view the work as close to reality as possible), a solution, along with a new tool or technique, should present itself.

Developers who stick to a plan and use existing tools, without inventing anything new to solve their problems, are probably not following an agile development process. A software developer should think about the product, how to build it, the tools they use, and how to improve those tools. Uninventive developers are lucky to be able to do a job that does not present novel requirements. But then again, perhaps they’re not so lucky after all.

Moving away from documentation and requirements gathering

No plan survives first contact with the enemy.

— Helmuth von Moltke the Elder (paraphrased)

It could have been the motto of the Agile Manifesto[AM01]. It could have also been said about Christopher Alexander’s post Notes on the Synthesis of Form[Notes64] work too. Much stems from developers repeatedly seeing their plans fall foul of poorly estimated costs. Overly complex systems often grew out of simple-seeming documents. Furthermore, customers were regularly unsatisfied with the results, even when presented with precisely what they had asked for. Using their antiquated design processes, modern architects also encountered the same obstacles.

The Agile Manifesto has an explicit preference for working software over comprehensive documentation. The value in not producing a lot of documentation up-front is much the same as Christopher Alexander’s methods, which required on-site presence and situational reviews. Plans have value, but they cannot be falsified by paper reviews. Reviews must happen at the place¹ itself. Indeed, the capacity to reject designs in the early stages is the reason why mock-ups were so crucial to Alexander’s process. The preference for working software is a preference for something that can be inspected, understood, and reviewed in situ. Immediate, visceral feedback is much more potent than documentation when determining the next step.

The manifesto was also making a statement by asserting that the documents typically produced during development had no inherent value. Only documentation for an extant product was valuable to the end user.

A further problem with documents typical of the time was denial of the mastery, purpose, and autonomy of the programmer. Plans were orders—something to follow. The only choice was whether to do as instructed or remove yourself from the project. This echoed Alexander’s thoughts on master plans for site development.

[T]he existence of a master plan alienates the users … After all, the very existence of a master plan means, by definition, that the members of the community can have little impact on the future shape of their community, because most of the important decisions have already been made. In a sense, under a master plan people are living with a frozen future, able to affect only relatively trivial details. When people lose the sense of responsibility for the environment they live in, and realise that they are merely cogs in someone else’s machine, how can they feel any sense of identification with the community, or any sense of purpose there?

— Christopher Alexander, The Oregon Experiment[TOE75], p. 23-24.

However, as is often the case with an immature collective, things went too far. Documentation is for more than just the end user. It provides fertile ground for insights and elicits unexpected requirements. It offers a way to document how you arrived at your decisions and what informed them. We must also recognise that some specific forms of documentation are mandatory. Indeed, some paperwork is used to verify that we have achieved our expected outcomes and reached an arbitrary payment gate, while others may outline contractual obligations to security or safety.

People overlook the powerful effect of writing on understanding a problem. Writing it out often helps you to notice gaps in your knowledge or reveals contradictory beliefs. I studied design patterns to write this book, but the writing itself has also been an educational process.

These days, end-user documentation—the only documentation implicitly allowed—is considered an indicator of poor design as the UX design should make the application learnable without it. User manuals embody marginal value to the developer; a library should be well commented and easy to grasp, avoiding the need to refer to separate documentation.

The Agile Manifesto’s signatories showed no fondness for the documentation typically produced as a byproduct of the development process. Presumably, this was because it was not a product in itself. They appeared to support eradicating documents filled with gathered requirements and technical designs produced solely to be followed. There is sense to this. Planning the whole development up-front is a bad idea, but only because it’s impossible to foresee the future. Consequently, the plan will be flawed; preparing everything at the beginning is only bad if you force yourself to strictly follow the obviously and inevitably wrong plan.

So, why plan at all? Well, because planning is faster than simply doing. Planning what you’ll cook for dinner for a week can simplify the shopping and the cooking. Sure, things can change, but at least you have an overall idea of what you have to work with. When you have an idea of what to work with, you can balance the overall effort and cost of the operation. And this is what Christopher Alexander did. His process included a lot of up-front planning. They budgeted for parts and the selected patterns to use in the overall construction. His work in Notes on the Synthesis of Form[Notes64] is all about extensive up-front plans, but they are plans for helping reduce mistakes, not plans that had to be followed blindly. This is how we arrive at the thoughts behind the often quoted “Plans are worthless, but planning is essential.” The point of a plan is to limit the required effort to the minimum, not to stop thinking ahead entirely.

A preference for working software over comprehensive documentation has been interpreted as advocating for the removal of all requirements-gathering steps. However, this leads to software development without an initial phase to gather tasks, to figure out the complications, and to reduce risks by ensuring bases are covered. Does up-front requirements gathering decrease risk in practice, though?

Preparation versus risk relates to the theory of quantity over quality. How practice, deliberate or otherwise, makes you better at that activity. It allows for mastery and gives you new perspectives for making better decisions. It also explains how evolution wins every game ever played. Producing an order of magnitude more software products to show to the customer to get feedback rather than spending days, weeks, or months studying the customer’s requirements sounds very similar the tale of clay pots found in the book Art and Fear[ArtFear94]. People often repeat it as an example of how quantity beats quality with regard to the ability to create the best possible product in the end.

The aforementioned tale goes like this: the teacher announced the class would be split into two groups. They would grade the quantity group solely on the weight of their work. However, they would use the traditional grading process for the quality group by basing it on the quality of a single pot. The experiment had the most curious result. The highest quality works were all produced by the quantity group. The moral of the tale is thus: To deliver the best possible output, practical experience and many iterations trumps time spent in preparation and deep study.

I would like now to relay a personal story in keeping with this tale. In college, I studied Music Technology, a course that explored the technological foundations of music and other media in the modern age. It included many aspects of music, from royalties and copyright law to physically constructing a studio. Other workshops were more musical, and among them was a series of units on the composition and production of musical tracks. Music production was the reason I had taken the course in the first place and was the joining together of many disciplines. I wanted to make music using better tools and to learn better composition techniques and songwriting skills.

My music-making capabilities gradually improved over the time I spent on these units. I took each track one at a time, possibly releasing a single worthwhile piece of music each term. That’s three months per piece. I saw how I was improving with each new track and was glad I was progressing. However, we had to decide what our final project for the course would be. I am a game developer at heart and have always wanted to make them, so I committed to a project consisting of writing all the music for a fictional computer game.

This project was a tremendous change of pace for me as, without fully realising it, I had signed up to produce more tracks for this single project than I had produced in the whole course up to that point. My portfolio of songs was somewhere in the region of ten to thirteen at the time; I cannot remember precisely. Nevertheless, I decided to produce a track for each level of the fictional game, with themed music for each act and a general motif for the whole suite. I also followed some assumed guidelines for game music, such as no chorus or refrains, just a steady mood, and reduced dynamics meaning a player could set a volume level and never have to listen to silence for very long or worry about the music being louder than the sound effects they were listening out for.

With these limitations in place and the sudden need for more than twenty tracks, which all had to be composed before the project’s due date, I started work. As I worked, I decided which instruments were core to the pieces and which were track-specific. I built up a set of practices for constructing tracks and learned how the filters and effects I used would sound even before I applied them. Overall, the time it took to create each song grew shorter as the project advanced to completion. When it came to the final piece, it took me no more than an hour from first note to final mix.

This is the part where my tale reflects the story about the clay pots. Whereas in the ceramics workshop, the teacher graded the students by weight, I was due to be graded on production quality and my understanding and implementation of the techniques we had been taught in class. I admit that I had been a very poor composer when I started the course; over time, I had improved to the point where I was merely third-rate. However, after the game-music project, the teacher who graded me said the last few tracks were the best he had heard me create. In effect, the more pieces I had completed and the more in the zone I had become, the better the individual compositions were.

More consequential for me was how, after the project, my new production quality stuck. Today, I am a wretched composer due to a lack of practice, but the sudden improvement at the time meant any music I produced after the project was elevated to a new level. For this reason, I would argue that the story of clay pots is incorrect, to some extent. Some people interpret the result of the experiment as being related to agile methodologies, such as Scrum, when they’re not.

A Scrum-driven project does not aim to build many individual products, producing one great product in passing, almost by accident. It’s still a process aiming to produce one final viable product. It’s an iterative development process. Therefore, it sits in the camp of the primary group—the group graded on the quality of a single pot. Ultimately, my evaluation was based on the quality of my final suite of music, not on how many tracks I had produced. Therefore, what we should take away from the clay-pots tale should be that it’s not the pot that gets better, but the potter.

This is an important distinction because you only get one chance to make the final product in some projects. Perhaps it’s difficult or impossible to build a larger final product from a smaller one. Iterative development might not be an option. In such situations, if you don’t look forward towards the final product and what it should be, it can lead to nothing at all. When engaging in these projects, there are often insurmountable problems that are created in ignorance during early development. For instance, consider the cost and complexity of fixing security issues after your software’s first alpha or beta release. So what the clay-pots experiment tells us is that we can be better during these projects if we understand that practice and preparation are two things which can sometimes be one thing.

In conclusion, agile development can be forward-thinking and include up-front investments, just as Christopher Alexander’s team selected design patterns to structure their projects. It can be about learning deeply enough to remove the need to look forward. Agile principles will prioritise faster development to facilitate swifter learning as well as building up good tools to make future work more manageable, just as Alexander developed new tools and materials to complete his constructions. You shouldn’t expect to fashion a great composition on your first attempt if you don’t study, but if you intersperse your studies with a hundred creative acts, your last one will be better than if you had spent the whole time with your nose in a book.

Agile approaches are suitable for training your team to get things right the first time every time you task them with a familiar project. However, this form of development can be wasteful when attempting exotic projects. This is why we need to use models and prototypes, as there will be major mistakes and lots of technical debt. Christopher Alexander strove to use flexible materials to avoid the costs of these unknowns—materials where errors could be undone or avoided, even as they emerged.

Every process depends on the wisdom of the team to instinctively know the right thing to do. Agile methods allow them to do that in the same way as the distribution of knowledge via a pattern language. It also allows them to become better at their craft through accelerated experience. If what you are building can be built up iteratively, then all the better, and in software, it usually can. Do not fear throwing away the bad work and early attempts. In fact, you should be fearful of not throwing code away.

Rebuilding whole modules from scratch will become quicker as the team grows better at making them through practice. What you cannot do safely is rewrite a module you didn’t write yourself. Also, you should rewrite early, not late, as your wisdom will have already begun to fade.

This kind of evidence might not be enough for you. You want to know why. Why is planning up-front not as effective?

The right wrong thing

User stories should tell you the right thing to make, while requirements analysis should tell you how to make the thing right. However, the latter process gets some things right and other things wrong. It can reveal literal and obvious things, such as what platform you need your software to run on, how much memory it has, what can be considered an acceptable response time, or how many concurrent users you expect to reach. These numbers can, of course, be wrong. An agile development practice almost expects such answers to change, even if they are correct at the time, yet these facts are knowable at the time. They can be detected, measured, and calculated, even if they are wrong at the end of the project.

Other things are entirely unknowable such as unexpected market shifts or secret projects that are suddenly and publicly announced. No requirements analysis can gather the unforeseeable. Agile methods can prepare you to handle these, but they can’t predict them any more accurately than traditional requirements-gathering exercises. And if they don’t happen, why do we still think that agile approaches are superior?

What’s potentially knowable but often missed are the requirements we unearth when project components come online; the results of interactions between parts previously developed in isolation. These are the emergent properties and complexities. A requirements-gathering phase can occasionally pick up on a few of these if seasoned developers are present, but even if you have experienced experts onboard, you should not hope to discover more than a slim majority of them during any planning phase. For this reason, projects should have a pre-production phase. A more fruitful requirements-gathering process can occur during a prototyping or proof-of-concept development stage.

Turning to the making phase faster has two benefits. First, it creates people with wisdom. In the future, during preliminary requirements gathering on a different project, they will know what requirements there will be for the things they typically work on.

Second, this change allows you to rapidly reach the stage in development where the requirements you missed during requirements-gathering make themselves known. They appear as integration blockers or arise when completing detailed design work, occasionally manifesting as insurmountable bugs at the lower levels.

Code enforces its requirements better than documentation because conflicts in documentation need to be actively sought out. In code, conflicts rapidly become compilation or implementation impediments. There’s nothing quite as immediate and obvious as being in the middle of developing a feature and realising it’s not possible to implement it with the current API or data layout.

Christopher Alexander’s process mirrors both these benefits. Planning at the site resembles eliciting requirements by working on prototypes, while continuous integration parallels the production and reviewing of building mock-ups. The builders using Alexander’s processes were given fast feedback on what didn’t work, and became better architects at a faster rate because of it. Again, this leads to wiser builders and the swifter discovery of and recovery from emergent problems.

This process scales with experience. As the critical elements of the project increase in size, the depth of knowledge and the breadth of expertise needed by the development team grow in proportion. For large projects, the developers need to be experienced at building at least medium-sized projects. The larger the project, the more the work must be repetitive for the whole project to be completed successfully. This repetition is not like a factory line but more akin to learning how to mortice a door or frame a window; repetition with variation leads to mastery. Working as part of a team and adapting what you have learned to support the project provides purpose. Meanwhile, understanding and improving the process at the site as a trusted team member gives a sense of autonomy.

Learning is essential, and this is why teams need to stick together. It’s also why we need teams in the first place. No one can do all jobs well. Some members have to carry the knowledge for specialist areas to save time for the group. If everyone has to learn every part of a production chain, then no one knows anything intimately enough to make insightful improvements.

No process is magic; not even Christopher Alexander could invent a system by which a complete novice could build a town from nothing. But he did produce a process by which a beginner could decide to forge a village, and from that process would emerge a community of buildings and an architect.

Furthermore, writing code also has other benefits. Counterintuitively, code is simpler to change than specification. It’s not easier to alter, but it is more straightforward to be sure your work is done. Code takes time to perfect, incorporating many keystrokes and moments of grumbling over failed compilations and red test runs. But even though it takes longer to get right, it is simpler to change because when every test is green, you know you have finished. It gives you immediate feedback on repercussions and adds value as part of the change. It’s also in revision control, so there’s a record of the change. This which helps decode whether any newly introduced usage patterns were part of a vital feature or an unexpected behaviour added by accident.

Many of these aspects are not mirrored in the physical building site, but moving mock-ups around lets you see the impact of alternatives quickly and supplies immediate feedback on the repercussions. Feedback comes much faster than when drawing with a pencil on paper. Unfortunately, these physical processes of making changes do not commonly produce historical records, so decisions and reasoning of physical construction can easily be mislaid.

Problems with acting early

The problems with the action-first approach are mirrored in physical development too. When requirements change on a grand scale, such as building regulations for physical construction or hardware availability for software construction, much of the completed work is wasted and more must be done to move the project back to a new starting point. The source of requirements can vanish, such as when a construction no longer needs parking or a piece of software no longer needs a feature because the operating system now takes care of that aspect. Of course, there are also new requirements, conspicuous in hindsight, leading to regrets that there should have been a little more forethought. Then there are the horrible kinds of change whereby the requirements were gathered, but misinterpreted. The literal requirements remain unchanged, but the solution must accommodate the new interpretation.

An up-front analysis could have revealed some of these potential sources of outside interference, but performing it later leaves these risks unexplored until you can better discern their importance. Consequently, neglecting any up-front requirements analysis is a foolish way to develop anything, yet doing everything at the start is equally daft. The point must always be to reconsider your motivations. What is the state of the world, and what do you currently know about the problem? Each step is a place to stop and assess where you are now and where you need to go next.

Sequences, sprints, and smaller steps

Processes inspired by Agile principles are better than the methods we were using before, but only in the same sense that walking through puddles is better when wearing waterproof boots. The question remains: why are we walking through puddles at all?

Before Agile principles, the favoured production practice was to have big plans and continually refine them until they were ready for use in product development. Lots of documentation would be in constant flux, and no one could read it fast enough to stay up to date. Some chose to ignore the rules and work how they wished. They developed first and documented second, if at all.

Agile development arrived as a solution emphasising direction over destination. We needed this because we see better by noting connections than by seeking out the endpoint. You often know the right direction before you know precisely where you’re going, just as you seek the door and not the room. Moreover, you predict the best course of action before seeing the result, and you should know the need before the implementation.

Christopher Alexander’s building processes included this direction-over-destination principle. His developments were carried out by applying local, stage-appropriate changes. His team regularly held reviews with the client before committing to anything they would pay for. These reviews included everything from the overall design to the colour of the details on the tiles. The significant part here is not the customer or the feedback but the regularity of the review. Rather than following instructions, they were building according to a plan by adjusting its details in response to the data resulting from the ongoing process.

In Scrum, the iteration cycle invites people to set time limits or reduce the scope of their tasks. This ensures that everyone takes the time to look up and see where they are. Scrum requires the team to meet with those who can give feedback on their direction. Then, they can appraise the situation and decide if they need to course correct. They can also inspect long-running tasks and check whether they need a change of plan. Do they need to change? Should they stop? Or can more resources be assigned so that they can be completed quicker? In effect, at any review meeting, the team receives feedback on the observable status of the project and can decide how to prioritise the remaining work, whether this leads to a change or carrying on as before. Once these decisions have been made, they decide on the next meetup date.

As children, many of us played a game of find-the-object, in which we were told whether we were getting hotter or colder. The game was simple. If the hider saw us getting closer to the target, they would say the word ‘hotter’, and if we moved further away, they would call out ‘colder’. This is feedback. Satisfying the customer through regular delivery of working software is the first principle of the Agile Manifesto. Satisfying means more than delivering; it requires we receive feedback on what impact it had. Some organisations need to remember this critical step. Either that, or they prefer their developers to play find-the-object while wearing earplugs.

The iteration cycles of Scrum usually assume multiple days between meetups, which can create a disconnect between the stakeholder and the team working on the project. Scrum attempts to mitigate this problem by introducing the role of product-owner. They stand in for the stakeholders, and are available to answer questions at any given time. It’s not the same as having direct access to the stakeholders, but it has other benefits. Stakeholders can avoid dealing with the poor communication skills of the development team. Having a charismatic product owner is not deceitful. In fact, it only becomes a problem when they don’t understand the stakeholder’s values.

You must act on feedback. You have to change what you do and how you do it. The order in which you make decisions is also critical, which is reminiscent of Christopher Alexander’s generative sequences¹. Generative sequences is the name given to sequences of steps or refinements that produce healthy structures. A healthy structure is well-formed according to the stresses, strains, and forces surrounding it. Feedback must be timely, and a good sequence provides helpful feedback at the right time so that it can be acted upon efficiently. Consider how some building block construction toys, such as Lego^tm, have excellent instructions while others seem inferior. The main difference is not the printing quality but the concern with which the instructions treat the mental model of the builder. The builder must have guidance for the right thing at the right time, and each step has a context. Good design patterns and good instructions are generative sequences. Moreover, good sequences generate a form while not demanding stilted, robot-like following.

So, things created through a process of sequential decision-making steps are of a certain quality, not only due to the steps chosen but also the order in which they are taken. One sequence will have a better outcome than another sequence of the same actions. As a code-related example, consider what might happen if you build all the features first and then fix all the bugs at the end.

Some orderings will only be able to produce a disappointing and inflexible final design. An example would be developing software without considering security or performance and then trying to introduce those aspects afterwards. Other arrangements of the steps will require minimal back-tracking during the final stages.

If the order of steps affects the final design, all agile approaches help because very few lock you into a specific order of activities. None of the elements of the Agile Manifesto prescribes what to do, and few specify when. The essential point is to be aware you don’t know the proper sequence and must actively seek it out.

In some ways, agile development attempts to parallel this building process. There is a preference for taking a route where you keep the client in the loop, and returning to them with prototypes and mock-ups to get feedback aligns with Agile principles. However, all of the agile methodologies ought to incorporate the practical, concrete practices of Christopher Alexander when extracting those elusive, profoundly human needs. I’m not talking about the problems caused by emergent properties—those are the constraints of the built product. No, I am referring to the gap between what the customer is willing and able to ask for and what they actually want and need¹. Even knowing the gap exists would be an improvement.

In the realm of architecture and building, the patterns found were all of a sort that produced environments for the end user. They cared less for the builder and very little for the ego of the owner of the completed buildings. If we consider a building contractor, a developer who funds and then rents out the building, and a potential family who will live in it for a generation or two, we can easily see the differences between them. In effect, the patterns were all about how the building was to be used in line with the actual lived experiences of the family members, not so much the building process. The affordances to the contractor who built the house tended to be those that were also good for future maintenance or for when the family wished to extend their home. In almost no instances were the patterns supportive of landlords or land developers.

As I studied design patterns, I saw an emergent property of these patterns for physical buildings, not just in relation to homes, but with regard to workshops and malls, hospitals and schools too. The patterns were almost always related to two or more of the following states in which people living in and around the building would spend most of their time.

• Rest and relaxation or recovery.
• Sustenance and personal maintenance
• Commuting and transportation.
• Communication and community.
• Labour and the care of others.
• Personal opportunity and spirituality.
• Family growth and adaptation.

These aspects of life required a different approach to building than an off-the-shelf product or modular building technique. They necessitated empathy for the specific needs of the end user. The builder needed to keep in mind the life to be lived by the inhabitants of the space once the job was complete. They needed to probe beyond surface or fleeting preferences and opinions and provide a structured but inviting approach to elicit the deepest, most enduring, and often quite trivial-sounding but fundamental needs.

Equally, an agile software developer needs to have empathy for the client. They must have a clear image of the final goal and should concentrate on how it provides for the user rather than the image the user thought of when they first commissioned the project. The user is an expert in their domain, but they are not an architect or a builder. They do not know how to ask for what they want when surrounded by examples of those requests ordinarily being considered irrelevant, insubstantial, or simply not serious.

In building and software development, the customer or client is, or at least should be, at the centre of the project. Their problems are the only essential problems to be solved. Their needs are the only needs that can be fulfilled and provide value.

Given these principles, the developer’s profit is contingent on correctly pricing effort. Profit can be increased by cutting costs or inflating the client’s investment, yet those actions would subvert the client’s needs or prove the process was not already efficient.

Gaining a solid reputation and taking that to the bank with a constant flow of work was more important when people grew their homes and extended their workplaces. Building was a sustainable practice, not a growth industry. Construction jobs were shorter, and people could gauge your work and hire you again. This is no longer true of physical builders as evidenced by the many attempts to certify trades-folk, so reputation can once again have an impact.

Unfortunately, software development started out in this position. Reputation was nonexistent for software development houses; there was no history to rely on. Those who commissioned software development usually hired in developers as there was such a small selection of large-scale project development organisations.

Nevertheless, we are now heading towards a world where reputation matters because scarcity is no longer a problem for a customer of small apps. The number of software houses that create small to medium-sized applications has grown tremendously in the last 30 years. In this new world where customers will say no, you must be recognised as someone who will solve their real problems and not introduce more as part of your process. We’re not there yet, but the frequency and size of projects developed on a for-hire basis is growing; at the same time, the number of reviews about developers is also rising.

Solving the client’s real problems requires an understanding of how to develop software and how to elicit the client’s deepest requirements. Only when you can find out what the client needs, despite their inability to ask, will you truly develop software that fulfils a need. Only when you have created a car for a client who wanted a faster horse will you know you have developed the capacity to satisfy those hidden requirements.

Slowly revealing the solution to a complex problem

Solving the puzzle of how to make something is one challenge, but knowing what to make is another one altogether. A customer could be unaware of what they need or be unable to explain it. The form of what you need to build might not even exist. In these cases, your development process could benefit from mimicking Christopher Alexander’s methods.

Many complex products are like this. Neither the user nor the customer will know what they want but they will know what they don’t like. This kind of negative-only feedback is effective, yet it can create expensive problems for those who are unprepared to work this way. Alexander always worked with a customer, resorting to keeping one in mind if they were absent similarly to how developers use personas to guide their work. Instead of guessing what they wanted, his processes were more keenly tuned to provide the things that would give them a more wholesome life. His team would take a deeper look at the patterns of the lives of those who were due to inhabit the buildings and sites once the development had ended. It’s these patterns of life that he observed most closely[Notes64]. The actions taken, the reasons why, and the values behind them all played a part in these analyses. They allowed for plans which not only satisfied the customers but also delighted them[NoO3-05].

Complexity is a word with a loose meaning in common parlance; however, there is a specific meaning of the term that Christopher Alexander managed to tame. It is therefore worth explaining what the word should mean to anyone interested in his solution. We may have some idea of the term when we consider complex projects; for example, they might include formidable problems or things made of many parts. However, I want to more concretely define the term and bind it to one particular way of thinking before using the word as much as I will in later chapters.

I encountered a better way to judge complexity when watching a talk by Rich Hickey entitled ‘Simple Made Easy’¹. Everyone can benefit from watching the lecture, as the content is broadly applicable, even if you don’t know anything about Clojure. (I certainly don’t.)

Complexity and simplicity are not concerned with how difficult or large a system is but how independent the inputs are from each other. A system with a thousand inputs and a thousand outputs, all wired one-to-one, is simple. However, a system with only two or three inputs, with every output depending on every input, becomes complex. One example is a throttle and clutch-driven car in which the movement force is a product of both the engine speed and the clutch commanded by a dynamic balancing act. There are only two inputs and one output, but anyone who has driven a clutched drivetrain vehicle can attest to the fact that it takes some practice to learn the complex interaction of those two inputs.

In software projects, the metric for complexity can be the number of things that need to change in response to any change you intend to make. You can measure at the code level and count the variables driving an output; those coupled together like a throttle and clutch.

Complexity can arise from technological choices. Lazy evaluation can have complex performance implications, and the use of smart pointers can entangle object lifetimes. Concurrency primitives for locking shared resources can deadlock at the most unexpected of times.

All of these have something in common—the elements alone are not a problem, in and of themselves, but challenging situations emerge from their relationships.

Now we have defined complexity, we need to specify how we will use the word ‘complicated’. Something with many parts can be complicated. A complicated sequence or set of related things must be connected in a specific order. The elements or steps only interact in so much as they depend on each other in a strict ordering in time or space. When you change one part of a complicated system, you have a small surface area for change propagation. There is a linear chain of effects. The effect of a change does not ripple back around to the element instigating the change, and the changes in the ripple are simple but frequently tedious (see protocols, build sequences, taxes and expenses). They are all complicated processes, but they are often predictable systems. They are knowable. It’s possible to accurately estimate the total impact of your input before you have seen the output.

Given this definition of complexity, we can now pose some questions. First, how does one tame complexity in a project? Second, what did Christopher Alexander do to rein in the complexity inherent in a building project? Finally, do these measures align with software development and Agile principles?

Regarding the first question, is it even possible to tame complexity? The answer is yes to some extent, and one way is documented in Notes on the Synthesis of Form[Notes64]. Alexander’s approach to building was an ever-evolving version of this first work. It included up-front requirements gathering and a discovery process for deriving final forms by concentrating on how things were coupled, which involved explicitly shying away from grouping them by the categories with which we might naturally associate them.

This certainly does not sound like the agile development practices we know. It also does not appear to address complexity. But let’s review for a moment. Christopher Alexander tamed complexity by understanding what it was. It was the coupling of changes. So, rather than creating a hierarchical architectural plan where each part finds a place in a group with others based on our prejudices, he grouped them by the strength of their change coupling alone. He would continually ask questions like, “If I change this part of the design, will that other part have to change too? And if so, does it improve with it, or does it make things worse for it?”

The Notes on the Synthesis of Form approach to architecture includes the following steps:

• Gathering all the elements that must be considered as part of the design
• Revealing connections based on their complexity—how they affect one another
• Finding the weakest-linked large groups, splitting them into separate conceptual groups, and finding a way to name or make a diagram of them.
• Within each group, repeating the search for the weakest connections and splitting them again.
• Continuing the splitting process like this until all solutions for all subsets of elements seem trivial.

The above process was recursive. Large cutting lines were formulated first, and then those groups were cut up in the same fashion. In this way, his early work revealed connected pieces of our environment. As he worked on more projects, he found some connections occurring repeatedly. Consistently naming these recurring situations led to the discovery of patterns. With patterns, he could resolve parts of a complex system without the burden of the concrete problem biasing the solution. He could now avoid the XY problem, being wise to the deeper need hidden beneath a shallow problem definition.

Many recurring collections of coupled elements tended to distil down to only a few happy, balanced solutions. However, these patterns were not actually solutions; they were the common properties of the organisations of elements solving those problems. The patterns were the pairing of the problems to be solved and what would be true for any good quality solution.

In a complex project, if you reduce the number of connections between elements or make the relationships visible, adjustments and estimates become easier to predict and contain. Changes in a project based on preconceived conceptual groupings cause cascading effects and induce further stresses throughout the system.

Adjusting the style of a window frame can affect whether a window can provide enough light to make it worth installing in the first place. For example, with the advent of UPVC windows, given the requirement for approximately 10cm of border around the glazing of an openable window, it is hardly worth the effort to build window spaces less than 40cm wide.

Furthermore, a style change can affect the number of bricks needed or whether a wall needs a reinforced steel lintel. Physical limits frequently dictate whether a design is valid or worthwhile. The availability of materials should too, but so often you see examples of people shipping halfway across the world just to have precisely what they ordered. In a sense, this precision and modularity based approach could be considered environmentally unfriendly.

With code, we see similar patterns of complication. You might include a global or a Singleton to allow access to a unique feature of your platform, but then later, a revelation requires you to offer two or more of these (e.g. after-the-fact testing suddenly being necessary as part of a security or safety audit). Now, everything which accessed resources through a Singleton or global will need to find a new way to pass a context so it can act and react according to the test bench setup.

Using reality to reveal coupling

Christopher Alexander’s solution to discovering how elements interact was to be at the site. He used many mock-ups with bricks placed dry, cardboard constructs and painted paper strapped to wooden frames, as well as anything else his team could do to trial an idea before it had to be, quite literally, set in concrete. This is like prototyping for software developers. Proofs of concept take us from untested hopes to feasible options or moments of clarity and despair.

Christopher Alexander used mock-ups to discover what you can’t extrapolate from paper designs, including how objects inside and out obscure or bounce light. The choice of an angle and colour combination may affect your mood but go unnoticed on a paper plan. How a view looks through a window may cause people to linger there, and so we see more passing space is required to navigate around those captivated by the vista.

We engage in a similar behaviour when doing exploratory programming, trying out ideas in the source rather than relying on paper designs or mental modelling. We make quick changes to prove that an idea might work in practice. Then we roll it all back and start properly. Using a spike like this shows us how the development will progress if we commit to it. We can identify how it might feel to build upon it later or even how it might be for the end user via a UX mock-up.

The most pertinent aspect is that the speculative activity should be done in the place itself, the actual site where the final work will eventually be committed. This means that you get to see how it impacts the final form, rather than just guessing at the impact. Unlike how when you work away from the main area and integrate at the last minute you learn of the problems quite late. The value of this activity is that you are always building towards gaining hindsight; effectively, you are already wiser before you lay the first stone.

In Domain Driven Design[DDD04], Eric Evans claims that domain models undergo many iterations and name changes before finding a ‘deep model’. As you internalise the core structure of the problems you face, you see nuances in the description of the problem. Those moments of recognition are a form of acquired discernment. When you can perceive these new differences, you also recognise the need for a different reaction to the phenomena. A different interpretation of the world begets a different response to it, and before you can discern a difference, there is no way you can incorporate it in your design. We cannot rely on hindsight. We must depend on many iterations, as it is the only way to see what should have been obvious all along.

We often only see the shape of the solution as we draw very close to the end of a project. The form of the problem is similarly revealed quite late. This is not a coincidence. We would not need to iterate if we fully understood the problem we were trying to solve or all of the problems inherent in any solution—if it were, software development would simply be a matter of data entry.

Development as a puzzle

You can compare this to puzzles. When you first encounter a puzzle, you are given it in literal form. Whether it be a word puzzle, a wooden or metal toy, a puzzle cube or a sudoku, when you first encounter it, you only have a simple concept of what the outcome should resemble. This is much like your customer’s goal. You have yet to learn how to get there but can visualise the final state.

The more you poke around at the puzzle, the more you learn about it. You uncover the sub-problems and generate local solutions. You’re no longer solving the original problem; you’re solving the steps towards it and generating new words for states you see and actions you can take. This is very much like programming, which is why people often say you need to plan again once you know more. They mean that you need to replan once you understand more about the problem and its sub-problems and have metrics for the value of the sub-problems’ solutions.

We work through puzzles by learning about the contexts around them and finding features of the problem we can fully understand. We can solve the complete puzzle only when we grok the smaller parts. Sometimes, we throw a lot of apparent progress away, which can be disheartening for some people; nevertheless, deleting code is not throwing away progress. Progress is accumulated in the knowledge of the people solving the problem and should therefore be measured in how fully a problem is understood. So you should regularly review the problem domain thoroughly and as early as possible.

You need to highlight all the sticking points and sub-problems and find a way to use those vantage points to see what you need to see. Sometimes, you will only know about a sub-problem once you have solved a different one. You will have to deal with many unknown unknowns in your puzzle or project, which is why collecting requirements must also be iterative. In Domain Driven Design[DDD04], Eric Evans suggests you should go back to the domain experts multiple times while developing a solution, not because they have new information for you, but rather because you can finally receive the information overlooked during previous interviews. It is only intelligible to your senses after you have built the requisite mental scaffolding to support the nuances of their statements.

This agile approach to requirements means a requirement can suddenly appear. It may have been misinterpreted, misunderstood, or ignored the first or second time. Later, due to an awareness of interconnected details and revelations from newly acquired discernment abilities within the mind of the software developer, it can suddenly appear to be a critical element within the grander scheme of things. When we listen and write things down, we only write down what we can understand. We cannot capture requirements that go unmentioned because they are too obvious to the person relaying them. We are also oblivious to what we fail to write down because we take those elements for granted.

To detect these unknown unknowns, Christopher Alexander worked within the domain whenever possible. Meanwhile, agile developers try capturing them by asking additional questions about each area. They can’t look out of a cardboard window, but they can ask whether a report is essential and what the business impact would be if it was delayed or otherwise unavailable. Sometimes, a tiny thing can have a huge impact. For example, someone might say, ‘… and then we email the report to three people’. You could interpret this as them needing the ability to email a report, but when you dig further, you find out that it is a release requirement. For example, the report is evidence required during a safety audit and must be archived and delivered with the build, but the other two emails are for interested managers or just because the person in charge of CI wanted to set up a liveness checker based on it. You must ask, “Why is that important to you?” to get these nuanced answers, which subsequently lead to entirely different requirements.

Given that revelation is part of any worthy process, it’s clear that the classic waterfall model of software development is demonstrably wrong. At least, the presentation of its process seems that way. We want to avoid that amount of up-front, context-free architecture, and integrating mock-ups and prototypes into the process will lead to some of the best and highest-impact design revelations.

However, many agile processes are unfavourable for different reasons, as they exhibit urgency problems. Urgent, essential tasks should be undertaken immediately. Important, non-urgent tasks should override urgent non-important tasks, but agile processes often prioritise work items the other way around. They select the most urgent thing at each stage until they blow up in larger projects.

Some will argue that this is not true as you should realise an important task is urgent as it’s not being addressed, but this implies that you have mature members on your team who are able to signal the problem ahead of the upcoming critical moment and filter out tasks that are not important. So, most agile practices lead to good outcomes, but this is only because they reintroduce features that were removed in the unwavering pursuit of ultimate efficiency.

Christopher Alexander’s approach to urgency was different. For him, decisions must be made and a problem fully understood before any irreversible actions were taken. Urgent features lead to discovery and help in making decisions. They are always about ensuring you make the right decision before it matters. As his process matured, the number of urgent tasks declined as the design patterns process for architecture led to decisions being made as part of a good generative sequence and before any money could be spent on the wrong things.

The difference here is that agility, as it is practised, does not separate the design and problem-resolving stage from the building phase. To some extent, that is the nature of software development. Proofs of concept tend to become final products, and prototypes continue to gain more features until they become shipped software. As the mock-ups of software are interactive, there’s a tendency to think it’s possible to polish them up into the final product. Unlike the cardboard and paper mock-ups of Christopher Alexander, from the outside, proof-of-concept code looks the same as the final form.

If there were no way to realistically ship prototypes—i.e., if there were such a thing as cardboard code—then the processes we put in place in the name of Agile would not be as severely misused. If we could use agile development practices to become better prepared, we could slowly reveal the solution to the complex problem and only pour the concrete when we believe we are ready. I have experienced a reasonable amount of success by actively choosing the wrong language to develop code in, purely so I can be sure it remains a prototype. If you know you need performance, write it in Python. If you know it needs to run everywhere eventually, write the code in Swift, F#, or some other single or limited platform language. This is a strategy I have employed to avoid needing to be good at politics and still escape the technical problems caused by trying to build a final product on the frame of a prototype.

Just enough and no more

Christopher Alexander ran his projects with a fiscal policy paralleling that of agile developments. He developed a method to drive the process towards a more natural sequence of growth from local decision-making. Traditionally, building projects went something like this:

1. They are budgeted
2. A plot is found
3. An architect is appointed and draws up preliminary designs
4. Planning permissions and other approvals are set in progress
5. A building contractor is brought in
6. The physical work of the construction takes place

With the stricter budget but flexible spending structure introduced by Alexander, customers would often get much more of what they needed and far less of what was unimportant to them. This echoes the principle of preferring working software over documentation and customer collaboration over contracts.

When you have a multi-stage process, you find budgets become a playground for corruption and profiteering.

At each step, the goal of the individual developer is not to build a delightful building for as little as possible but to make as much money from the building process as they can without breaching their contract. Essentially, cost-cutting practices increase costs.

Agile development could¹ break this cost inflation by doing the same thing Christopher Alexander did. The budget could be set, and the delivery should be decided upon. If something costs more than expected, it is made smaller, or something else takes the hit and is reduced in quality/quantity or withdrawn. No one is allowed to spend the excess because usually there is none. And even if there is, it is returned to the entity commissioning the project.

We reinforce this further by following another tenet of Christopher Alexander’s processes: delivering regularly and getting feedback from the client. This way, they also get to see the work in progress and decide what they really want now that they can see the product closer to the final form. The clients don’t pay for what they didn’t ask for. Instead, we offer them the chance to see what they need to ask for.

In most of the projects run in the Alexandrian way, builders and architects worked locally, iteratively, and directly on the site. They were present in the client’s context. The time cost for uncovering a revelation and getting a response was tiny and sometimes non-existent as the client may have been part of the labour force. This waste reduction in the form of zero or minimal response time requires a solid link to the customer with regular feedback sessions or a knowledgeable client representative.

Working on site also meant that the architect and the builders were practising continuous integration and delivery with bricks. They included other aspects, such as continuous improvement of their processes, as they built the necessary tools on demand. They designed new ways to construct with prototypes and proofs of concept. In one project[TPoH85] they even had brick machines on site to create just what was needed and invented novel roofing techniques using thin wood strips and concrete-reinforced canvas to match the available local resources.

All this was just enough and no more. Christopher Alexander did not use these projects to fund some irrelevant side research. Instead, he charged a fair and reasonable fee. He did not overcharge based on his reputation or undercut to get the contract. This would later prove to work against him, as the wider world did not play by his rules.

Modern old way

In 1882, the old way received a blow like no other. Frederick Winslow Taylor was promoted to machine shop foreman and was free to work out a new way to approach getting the workers to produce at greater efficiency. He’s known for the invention of the time-and-motion study, and this approach has introduced a new level of efficiency and productivity to many industries. As a consequence of its success, management has become a more scientific occupation and now impinges on the adaptive nature of skilled workers.

For some tasks, the approach works very well, but even to this day, managers are often ignorant of the principal disparity between physical labourers and mind-workers—the former group primarily works to live and for the community of the effort, while the latter are more strongly driven by mastery, autonomy and purpose.

Later on, Taylor produced a book which includes a comment indicative of his beliefs:

It is only through enforced standardization of methods, enforced adoption of the best implements and working conditions, and enforced cooperation that this faster work can be assured. And the duty of enforcing the adoption of standards and enforcing this cooperation rests with the management alone.

— Frederick Winslow Taylor, The Principles of Scientific Management[Taylor1911], p. 83.

When I read this, I picture someone who does not trust their workers. I believe they think of them as children or cattle. I recognise the tone of someone who believes management, with no experience of working with a new technology, will somehow know how best to use it, and that those same managers will be able to direct their workers without ambiguity.

A hundred years have passed, and these words still echo in the halls of management. Those in charge of organisations still generally believe in command and control. They measure outcomes and use cost accounting, forecasting next year’s chickens based on the eggs in this year’s baskets. However, software development has proven problematic.

Software developers consistently underestimated their work and missed deadlines. Something was wrong, and management didn’t know how to fix those unruly techies. Knowing they needed to get on the IT money train, the heads of production were never going to give up on attempting to wrangle them into good behaviour. Yet none of them would even consider giving up their command-and-control approach to projects. In fact, the worse the experiences of the project manager, the more tightly they turned the screws. They demanded more and more detailed estimates and finer task breakdowns. At least they were extremely efficient at creating a demand for printer ink and paper.

This lack of trust led to even worse behaviour. Demotivated mind-workers are a revolting bunch. Those without autonomy started to feel like cogs in the machine. Those lacking the space to develop their skills began seeking job security through other means. As goals grew more ambiguous, purpose and shared vision fled, destroying any sense of achievement. We spent a hundred years increasing efficiency and a hundred years disintegrating pride.

I find the whole story so sorrowful. The old way generated motivated workers; the kind we want to build projects around in an agile environment. When you enable skilled and motivated people to do their best work, give them clear goals and let them find the best solution, you always get a better solution than if you tell them what to do. Christopher Alexander’s team worked like this, and their clients began to see how motivational it was. When the project is goal-driven—purpose-driven to satisfy a real and present client—it’s propelled by virtuous pride. We’re driven by the pleasure we take in seeing a smile on someone’s face in response to our efforts. We do not seek awe but to satisfy and delight, and this is much healthier than being profit-driven.

Another aspect of the old way is the notion of local people helping where they could and training to support themselves in the future. Christopher Alexander followed this approach in the Mexicali project[TPoH85]. The people who eventually lived in the homes were also part of the labour force.

In Team Topologies[TT19], we see the concepts of stream-aligned and enabler teams. The idea originates from looking to reduce the cognitive load for others by ring-fencing individuals who are knowledgeable in a sub-domain so they can be available at short notice. In a large project, we generally align sub-teams with specific product features; these are the stream-aligned teams. When their members have to learn how to do uncommon but mandatory activities, it can become a form of waste. Whether you are working on a computer game or a word-processing application, no matter what sub-project or feature you are working on, you must set up and maintain continuous integration, static-code-analysis, issue-tracking, or other technically complex supporting systems. Enabler teams help to keep the stream-aligned teams on track. They act as knowledge-on-demand resources when dealing with tasks that the stream-aligned teams only need to do once.

The locals in the Mexicali project were the stream-aligned teams with a purpose and vision. Those coming in to help them with processes and skills in construction and design were their enablers. The enablers helped the teams achieve necessary but daunting tasks. For example, builders on the enabler team taught the locals how to set up and work with the brick-making machine. The locals did not know how to plan for plumbing or other utilities, but this was a one-off event for each family to get them past a bump in the construction. Enabler teams provide on-demand, just-in-time knowledge. This bears a great similarity to the workshop, where an apprentice and a master of the trade would work side by side, with a specialist being brought in to do the irregular but occasionally necessary work. When we form and maintain a team under agile development, we forget about this spontaneous need for knowledge and often ask a team to grow instead of supporting them. A team should self-organise around a problem but demand the right to remain ignorant when it is more effective.

Some programmers do work this way. They retain the option to work on tools as they see fit, according to their experience of what would make future work effortless, safe, and efficient. Craftspeople would look for ways to improve their work processes when there was a bit of downtime. Leads would chat with their staff over a beer at the end of the working day, and grievances would be aired as they are now, during a sprint retrospective. During a lull, they would sharpen their saws. During a longer one, they would invent a new tool altogether. However, this required slack. Without slack, there is no time for reflection or improvement. The time and motion studies took it all away. In so doing, they wasted those innovation-generating skills of the workers. Have you ever noticed how programmers who have slack and autonomy often have the best suite of tools?

Agile principles emerged when like-minded individuals observed management’s response to the software crisis in their organisations and the workplaces of others. It was a response to those regressive actions and was a solution centred around practices that were conceivable at that juncture. The strength of the Agile Manifesto[AM01] stems from a particular lack of strictness about its solutions. The presence of simple preferences over laws solicited many interpretations and made the migration more palatable for managers who wished to continue commanding and remaining in control.

Because the link was weak, the Agile movement did not incorporate various aspects of Christopher Alexander’s theories and processes. Some remain missing because the movement never introduced them, but others are missing because they faded away. Perhaps they disappeared because we failed to understand their value, so these activities were not deemed worthy of protection. However, a more potent force may have removed them intentionally.

The demand for fiscal control was only minimally adopted. Agile development has almost entirely dropped this element now. The practice of bringing the customer into the work process has diminished along the way, with many contemporary interpretations of Scrum¹ assuming product-owners to be both sufficient and necessary while neither is true. Many other aspects of feedback garnered through presence at the site have been lost, and the approach of taking small steps has been diluted into sprints or iterations of delivery rather than opportunities for direct and instant feedback.

Although we cannot trace the Agile Manifesto directly back to Christopher Alexander’s work, the recognition of software design patterns can. Indeed, the concept of software patterns may have lain dormant for decades had it not been for Ward Cunningham and Kent Beck picking up on the connection in 1987. They approached a design problem the way Alexander did by developing a language for the project. They used patterns to guide novice developers². This original work on design patterns in software development was more closely aligned with Christopher Alexander’s processes, and the simple pattern Collect Low-level Protocol was closer to an Alexandrian pattern than any of the GoF’s examples. Deviation from the principles of A Pattern Language[APL77] is one of the reasons why design patterns failed in the way they did. But this chapter is not about failure. That’s what the following one addresses.

Did Patterns Really Fail?

Some may think it obvious: design patterns did not fail. However, whether they failed depends on what you mean by ‘design patterns’. In some interpretations, they have been and continue to be wildly successful. In others, they have faded away and no longer exist in mainstream consciousness. With so many definitions of what a pattern is and so many of them agreeing on patterns being related to the GoF book, can we at least decide on whether any of those patterns failed? And to what degree and in what ways?

Design patterns aren’t design patterns

There are three reasons why the GoF patterns aren’t patterns in the Alexandrian sense. The first is the simple and acknowledged fact that their patterns are solution-oriented rather than problem-oriented. The second and more contestable point is that they are idioms of the programming languages of the time. The last is the concern that they aren’t alive. We will discuss this final point in greater detail later, but for now, consider aliveness to be the properties of self-starting, adjusting, and adapting as necessary. Living patterns engage with their neighbours, making it easier for surrounding elements to find satisfying configurations.

Solution-oriented

For many patterns, we need to introduce a starting point: the problem. All the GoF patterns are visions of a final form—a ready-selected solution. The process by which a problem is understood and resolved is the lesson we want to teach, but a solution doesn’t do this. Alexandrian design patterns are problem-oriented. They are about wisdom and experience when faced with problems encountered many times before. Solutions tell you what it looks like when it’s done, but people learn best from questions, counterexamples, or stories with conflict. People grow the most when they are invested in outcomes and aware of the stakes—when there are unresolved forces.

Even if they were patterns, not idioms, the GoF patterns lack the problem orientation of Alexandrian patterns. They lack the required tension.

All A Pattern Language[APL77] patterns are about repeating problems, not repeating solutions. This difference is critical because patterns aren’t simply advice on what to do. Patterns give you the structure and prep work for the questions you must ask yourself when encountering a problem. All the patterns in A Pattern Language provide a plan for a solution, but the opening section of each pattern is a recognition of a problem, with context and forces.

The Strategy pattern might be an actual pattern in software design, but it’s presented as a solution to the problem of wanting to specify behaviour by a parameter. What’s missing is a context in which you might want to transform existing code to such a spec. A pattern should be a solution to a compelling problem—a set of forces demanding that you deal with them. Without the context, Strategy is too similar to a variant of the Factory Method, State, or Command pattern, and it can be difficult for someone to see when you might choose one over any of the others.

Indeed, you could claim that State and Command are both extensions or specialisations of Strategy. The only requirement for State is a contract between the state object and the context object defining responsibility for change. For Command, you only need to ensure the Strategy objects contain the information about the receivers of their effect. The issue here is that the problem of generating commands and handing them to the invoker is the same problem as selecting a formatting algorithm and offloading it to the line-ending calculator. The problem gains nuance as you move to dynamically changing strategy objects, such as when you think about behaviour as state or move to include extra information about how to carry out the strategy, such as with Command. What’s gone wrong with this approach is how, by writing these as separate patterns, we have lost the option of considering strategic or stateful commands. A command could act differently based on its state as part of the strategy or template method. Separation of concerns isn’t always a good idea.

Idiomatic

But let’s talk about idioms. Some patterns are examples of how things were done at the time. To my mind, Memento, Bridge, Builder, Mediator, and Visitor are all examples of solutions that aren’t self-forming. At some point, people just agreed to work that way. Other alternatives exist, at least for the problems they intend to solve, so the patterns feel idiomatic of the languages at the time they were documented.

Idioms aren’t patterns because they’re not repeatable discoveries. They were decided or imagined, not a spontaneous consequence of their environment. For example, Memento is meant to provide a way to store the state of an object under change without violating encapsulation. The solution asks for a wide interface for the originator and a narrow interface for the caretaker. However, there is little in this pattern not dealt with by an object serialisation interface, generic for any type. It need not be aware of the originator to fulfil its role. In some languages, this is a given feature. The Memento pattern seems like an idiom that is looser than the relatively commonly understood but undocumented pattern of Serialisation.

What can reach beyond is a pattern that considers the problem behind the inclusion of Memento: the problem of state recovery. Consider a system that has copy-on-write capability and uses immutable data structures. In such a system, we can interpret Memento as an object that holds onto a reference to older object states. Unwinding the state is a trivial case of recovering the previous reference. In other systems, an object from the originator may not be enough. You may need more context to undo any changes.

If we consider Singleton, you might think this is a typical usage pattern appearing in many different places, but the form of the solution is idiomatic. Better solutions of when and how to instantiate the solitary object exist and would be preferred. But the Singleton pattern provides a stable, understandable, idiomatic, and wrong option for all to use and copy, and as with many idioms, it’s not quite bad enough to cause problems most of the time.

Not alive

The last point of contention—the claim that the patterns are not alive—is a little more subtle. Given how difficult it is to find evidence of lack of evidence, I make the following argument with limited confidence. The design patterns in the GoF book aren’t living patterns.

In this case, we’re interested in whether they are self-starting and neighbourly. The requirements for aliveness are contrary to those of an idiom. A pattern must come into existence of its own accord, usually due to emergence from a context, not simply agreed upon. You prove liveness by finding the pattern presenting itself as a novel, locally sourced solution at various times and places. In physical architecture, multiple spontaneous incarnations must be sighted for a pattern to be recognised as such. The majority of the GoF patterns seem lacking in this respect.

Outside of the group members who collected them, many listed patterns only have limited evidence of prior existence. For a problem-solution pairing to be a pattern, it should be self-forming. Not finding examples matching these patterns in the wild, outside of any environments where the GoF had influence, would indicate they could have been memes or idioms of those specific developers rather than patterns.

This is not to say the GoF patterns are not self-starting, just that there’s little evidence that many of them are. The Iterator, Strategy, State, Template Method, Flyweight, Factory Method, Prototype, Adapter, Observer, and Interpreter are all patterns you can see in code that is design pattern blind if you know what you’re looking for. For example, the C++ Standard Template Library includes and extends the core concept of an iterator as an object to a remarkably flexible final form.

But, and this is a big one, try collecting all those examples together. Find someone who does not know about the GoF patterns and ask them to sort them into groups. You might be surprised at how they collect them into different sets than someone who has read the GoF book[GoF94].

Beyond self-starting, there’s the aspect of linkage with other patterns and elements. The patterns in the GoF book are all independent and separate except where they seem dependent and inseparable. Patterns are neighbours, neither coupled nor isolated. The GoF patterns do not automatically support each other. The patterns in Domain Driven Design[DDD04] strongly support each other but are not so tightly coupled that they become part of the same pattern. The first POSA[POSA96] book refers to pattern systems and collects them together as an Alexandrian pattern language.

Unchanging

Christopher Alexander demanded we raise the practical questions about our projects—the questions asked by those who must live with the results. Things change, and people’s lives change, too. Our relationship with space changes over time, as do the materials we use for construction and the choice of location we wish to develop. This was the reason the traditional methods of building and architecture began to fail and what prompted Christopher Alexander to write Notes on the Synthesis of Form[Notes64]. Modern techniques fail even though they adapt to change, but change has already dealt a blow to the traditional approach.

Any patterns we adopt must be part of a process by which those patterns can be reviewed and improved in later years. This is why we should challenge the GoF book[GoF94] in light of our findings about complexity and simplicity. The book requires an update because better solutions to the problems it addresses exist, and those solutions don’t fit into the book’s structure. The update should include warnings about the issues that were found when some patterns were introduced. New solutions replacing old ones must be presented clearly, not overshadowed by a popular but ageing reference.

The need for such a process of review and refinement is why I am not happy about suggesting replacements for the GoF patterns in this work. I want to introduce the idea of replacing Interpreter with the twin patterns of Specification and Monad and move away from the older description to make the value more apparent. But the future holds different problems and I do not have unlimited foresight. In some places, we need safe code over flexible code, in which the pattern No Unsafe Paths plays a part. We need faster code in others, in which a suite of data-oriented design patterns¹ would play a role in resolving forces of wastefully slow software. Replacing the GoF book would mean including too much or not enough.

The patterns of development will change as the languages we use change. Many books showing us how to develop with these languages have already been published. Some programming languages aren’t even upfront with you about the fact that they are languages but they have patterns all the same. For example, who would say developing a Node.js application is the same as writing vanilla JavaScript for a single webpage? And because there are different dialects of these languages, specific patterns have emerged. There are patterns of working within any common language or framework. Popular game engines have their own patterns alongside the idioms. Hardware constraints also lead to patterns. Embedded, high-frequency trading, and mobile development are fertile ground for the emergence of new patterns.

And that is the point. Patterns emerge. They may be eternal forms, but they can also be forms of a transient environment. New patterns may be as discoverable as the processes for multiplication or making rope. Remember, even these patterns were discovered with rational thought and organic matter.

The abundance

Before the GoF book[GoF94] was released, patterns were present and known about by quite a few people. However, the published design patterns were not clearly labelled as such. Some were described as processes, others as guidelines for a project. But discoveries were soon labelled as patterns after the GoF book was released. It’s as if the presence of the book legitimised the terminology of patterns for software engineering. However, the quality of these published patterns varies considerably. Those published in the PLoPD books¹ went through a shepherding process, so they should portray the better-curated side of the movement, but even they are lacking in some surprising ways.

The shepherding process helped people write up the patterns they had found. It was intended to guide a pattern author to produce a text that fulfilled the criteria of a design pattern and provide feedback on whether the pattern was faithful to the concept. In practice, this was achieved in a fashion comparable to a writers’ workshop. Any pattern that went through the process should be free of obvious mistakes and, by virtue of having come out the other side, should be worth reading if you encounter a similar problem.

As a modern reader reading these patterns, many strike me as both hopeful and naïve. Many of them aren’t even patterns. They suffer from similar problems to those of the patterns in the GoF book. At the time, the process of finding patterns and the form of patterns were still only vaguely understood by many. And there were other problems. Due to their nature as a collection of proceedings or from different books with different authors, they are inconsistent in their presentation, content, and size. All of this adds to the difficulty of using and reading them.

The patterns presented in Christopher Alexander’s A Pattern Language[APL77] are many—the book includes 253 patterns in total. But they are at least all readable, consistent, and openly aware of their validity. This last point is made clear by a notation on the patterns: a single or double star, or the absence of any. Alexander and the other authors were very aware of how difficult it was to be sure about whether a pattern is good and wholesome.

In this sense, each pattern represents our current best guess as to what arrangement of the physical environment will work to solve the problem presented. The empirical questions center on the problem—–does it occur and is it felt in the way we have described it?—–and the solution–—does the arrangement we propose in fact resolve the problem? And the asterisks represent our degree of faith in these hypotheses.

— Christopher Alexander, A Pattern Language, p. xv.

The term hypothesis is used to describe each pattern, pointing out their stance on their discovery. Perhaps also indicating a slight hedging—a self preservation if it turns out they were mere wishful thinking. Even so, they were conservative in handing out their approval of the patterns in the book. Very few attained the two-star status reserved for those patterns describing invariants found in all wholesome solutions to the problems they framed.

An abundance of content is not always a good thing. In the realm of software design patterns, it was not beneficial for pattern authors or consumers. Without curation and strictly enforced well-defined guidelines, many submissions were published regardless of whether they were usable, correct, or even found in real life.

As I researched these older patterns, I became disheartened and felt some developers included these hopeful patterns just because they wanted them to exist, thinking it would be nice if they came true. I can understand the thought behind doing so and how a charismatic author might weave a good tale and convince a group or shepherd to sign off on the work. Other patterns appear to show off what the authors knew or were able to solve. These patterns anger me. Tainted by ego, they are all one-off solutions and never patterns. I believe their purpose is not to teach but to stake a claim.

Reading these early patterns, you get the impression that these egoistic and hopeful specimens were taken from samples of one or fewer. Sometimes, they sound like an idea of something that might exist. Writing down what you hope to be true is a mistake many non-fiction authors make, and I hope to avoid doing so here.

As the movement aged, and with later books, the quality and pattern-ness of the published patterns increased until the last books comprised only very well-curated content. The last PLoPD[PLoPD5-06] book contains some outstanding patterns. I have trouble finding fault with many of them, even though most still seem to be solutions to specific problems rather than principles for generating solutions.

Because of their abundance, even if all of the published patterns were proper patterns, their users would suffer because there’s too much to take in. Part of the charm of the GoF book is that it only requires you to learn 23 patterns. With thousands out there, where does one start? Which pattern collection do you browse first? Whose patterns are foundational? Whose would be helpful in your area of development? Again, this is a problem stemming from abundance without curation and cataloguing.

Our modern world has countless songs and films, and finding one to suit our tastes is undemanding. With patterns, it’s a different story. Is this simply the difference between entertainment and engineering? I don’t believe so. The problem is how we search for what we want. An abundance of movies is not a great disadvantage for the consumer; there are genres, and people know what they want. With patterns, the genres are unknown and sometimes, we’re too ignorant of our need to know we should even begin the search.

So, while literal abundance is not to blame, without the necessary protections, it became a breeding ground for many other problems. It was likely the root cause for why many better patterns were lost amidst the noise before it all turned to silence.

Loss of meaning

The most subtle yet deleterious failure was the deviation of meaning to that of an idiom. Patterns are very different from idioms. They would not have been as fascinating to Christopher Alexander had they carried the same value. However, given how so many design pattern authors have presented idioms as patterns, the distinction between the forms may not be sufficiently clear. To help, I shall go the extra mile and let the cat out of the bag by explaining what an idiom is, why it’s different from a pattern, and what unique values it brings.

Idioms are natural expressions of an intent by those fully embedded in the medium. For native speakers of a language, it means that words in contexts gain a new meaning. We can differentiate idioms from other word forms by their unique nature. For example, I did neither release any feline from a container nor travel any considerable distance when writing the previous paragraph. Those words, in those configurations, mean something different than their literal meaning.

Idioms are agreed upon, whether consciously or unconsciously, by the group using them. An individual is unlikely to spawn an idiom. They are not a ‘found’ thing. They don’t naturally reoccur, because they are an element of the momentary culture. They are the acceptance of an idea rather than a strongly self-selecting thing that forms from the properties of an environment. Because of this, we can question why an idiom exists and who it’s for. These are clues to the idiom’s value to us both now and in the future.

In programming, idioms are the accepted or preferred way to achieve goals in those languages or paradigms. This latter point is why some classify the GoF patterns as idiomatic. They are examples of solutions to repeating problems but for object-oriented design alone.

Programming idioms can communicate an intent through a set of steps. If you think of steps as verbs and the objects upon which the steps are taken as nouns, it’s easier to see the link. Idioms are domain-specific in the way patterns are specific to contexts with particular properties. But there are many domains for idioms to cling to.

• Idioms of compiled languages
• Idioms of functional languages
• Idioms of C++
• Idioms of programming in your specific team
• Idioms of academic programming
• Idioms of high-performance programming

Each of these domains can overlap with the others. There are potential idioms of programming in your academic team of high-performance C++ programmers using a functional style. There are so many domains where idioms might occur that it is implausible to list even a tiny fraction of them. Think of them instead as modes of thought—fields in which you can assert invariants or immediately know what would be considered valuable through that lens. Another way of thinking about idioms is as a form of etiquette. They can be rules, but they are artificial even when beneficial.

An idiom, like a word, extends the language. It’s easy to recognise and comfortable to work with, as long as you’re part of the group that understands the in-joke. Because of this, we prefer to write idiomatic code. Code is more easily seen as correct and inflicts less cognitive load when its appearance matches our expectations.

So, why are these not patterns? After all, patterns are often referred to as extensions of a language. Pattern languages communicate relatively larger ideas through smaller, more commonly understood ideas. But patterns and idioms, for all they share, have some significant differences.

Patterns aren’t always constrained to one location or level of scale. They will change in appearance at a different location or level but can be the same fundamental composition of interacting forces in a context. The context does not have to be limited to a specific level of detail, language, or medium. For example, the physical building pattern 159 Light on two sides of every room creates places with abundant natural light. People can see things clearly in rooms with little glare. We feel good in places like this because we can observe the small movements on people’s faces and, therefore, feel better connected to them. This same pattern plays out when using lighting rigs in film and TV. When we want to engage an audience with a character, we light them with little or no glare so that the slightest emotional details are perceived. It’s an entirely different level of scale, but the pattern forces and the context match.

Patterns are self-starting. If they didn’t exist already, they would naturally occur under a different name when the same forces arose. In comparison, idioms tend to be cultural elements. Sometimes, an idiom is something that came along at the right time to be accepted as the right way. There’s also the aspect of idioms being a culturally enforced right way, not reinforced by environmental feedback the way patterns are.

A pattern is a word in a language because a word is needed to describe what it does and where it fits in the grammar of the whole space. Idioms are more like the word choice, spelling, or sequence of words used to realise a solution for a specific in-group. If you know C++, you may have encountered the erase-remove idiom. It’s an idiom of deleting elements from a vector¹. However, the algorithm for removing elements from a vector—by shuffling them down and only resizing the vector itself when all removals are complete—is a pattern. The solution to the problem of erasing elements from a vector is a self-starting pattern reoccurring in different languages and paradigms. How it (the pattern of vector element removal) is implemented in C++ with the STL is with a two-word sequence (the idiom of erase-remove).

For another example, we can consider astrology. No, really. Keep reading, please. At the root of astrology is the recognition of shapes in the stars we see in the sky. I’m not particularly interested in which sign is rising or where the moon was when I was born, but I am interested in the concept of constellations. It’s not something unique to any one particular set of people. Constellations are a pattern of human objectification of the stars. However, the specific stars and the formations we named are idiomatic. Each isolated culture had a distinguishable set of relevant clusters of stars. Some overlapped, but many didn’t. Constellations are a pattern of perception, but each zodiac variant is an idiom.

Because an idiom is deemed valid by social contract, they are unlikely to persist as long as patterns. In contrast, a pattern is considered authentic only by judging its intrinsic virtues, such as whether it’s autopoietic². The nature of idioms often leads to their destruction, as the influence of new language users overrides tradition.

Now you can understand why, despite some brilliant people claiming that all the GoF design patterns are idioms, they are wrong. Some pattern are entirely self-starting from requirements in the domain of object-oriented development. If you attempt to find solutions to design problems and limit yourself to objects, you will, in most cases, come to some of the same patterns as those recorded in the GoF book. Like the bow and arrow, they are patterns forming of their own accord, without requiring outside influence to rouse them. When you search for a way to decouple behaviour from the trigger while constraining yourself to using objects or try to recreate function pointers in object-oriented design, the natural solution is to create an object representing a function call, which is the Strategy pattern in a nutshell.

But idioms can also be fantastically useful. Gathering them and presenting them to those new to the language can hugely impact their ability to comprehend and contribute. Without idioms, you must figure out what each set of words means each time you encounter them or invent a new sequence satisfying your meaning. But idioms are local, in time and space and purpose. Having so many idioms in the catalogue of patterns made it very hard for anyone to understand what a pattern should be. This led to the further dilution from idiom to technique.

As the publications on patterns continued, new areas opened up for pattern coverage. As the breadth increased, the understanding of what patterns are became idiomatic. We started seeing design patterns categorised as any recognisable recurring form in a design. In user interface (UI) and user interaction design, the meaning drifted further until we witnessed UX design patterns, which are all idioms in a pronounced way, as they depend on history and UI literacy. If they were patterns, someone new to computers would not have to ask what the three seashells means, I mean, what the three-line hamburger button means.

When you look at recently released design pattern books, they are often just lists of techniques. Some examples I have on my bookshelf include the MapReduce Design Patterns[MapReduce12] book from 2012, React Design Patterns and Best Practices[React17] from 2017, and Machine Learning Design Patterns[MLDP20] from 2020. A few patterns in each book might be patterns, but the books are dominated by techniques and solutions. With that, it’s clear we have liberated the term ‘design pattern’ so it can be used to describe any book as long as it has a collection of handy tools for solving problems in a domain. Well, that’s unfortunate.

Unfindable

When hunting down a pattern to use, you will not locate a well-defined or widely recognised index to them all. Many are poorly named or hidden inside another language behind a further layer of contexts.

Naming patterns is tricky. Some of them have names that seem utterly unrelated to their purpose¹. However, knowing which one you are looking for is difficult, even when the name perfectly captures its essence. Because we named software design patterns after their solution form, they dislocate patterns that are united by a common cause but join those solving tenuously connected problems. This is how most software patterns have been catalogued, so the problem surfaces in most examples. It’s even true for a handful of the patterns in A Pattern Language[APL77]. It’s a real shame we misunderstood this aspect of cataloguing.

To understand what it means when I claim design patterns are typically presented using the wrong aspect, it’s worth considering a made-up pattern related to real-life architecture and buildings. I will show how something—when described as a pattern from a solution rather than a problem perspective—becomes an unwieldy mess. I aim to align with the style of the most famous software design patterns and show how it misses the mark. For this exercise, I will take an elementary example—a pattern for passing through a wall.

Who would say the pattern of a door was not a design pattern? It’s a structured solution to a recurring problem, used repeatedly. So surely it is a pattern, right?

Some Doorway implementations will lead to the outside and the public world, while others will bridge the gap between internal rooms. The Door element in a Doorway to the outside may need to be:

• Resistant to weather
• Resistant to attack
• Secured against prying eyes
• Resilient to accidental damage incurred by collisions with other vehicles
• Have low wind resistance when used to separate open spaces such as fields

The level of weather resistance must accord with whether the Door needs to survive the environment or whether the Doorway should keep the weather from passing through and into the structure’s interior.

The material for a Door depends on its final use, so be sure to determine the strength, weight, fireproofing, and waterproofing requirements before settling on a design. Any Door on a boat or submarine has critical constraints in this regard. Other necessary material properties, such as transparency or flexibility, may also apply. An inflexible Door to a field or garden may become brittle or warped and unsuitable for use because it no longer locks effectively. The Door on a greenhouse or a shower should be transparent in most cases. A Door leading to a beautiful outdoor place, such as a garden, should at least be partially made of transparent material; however, you may wish to choose a soundproof material if your children are loud.

Rooms have a range of privacy requirements, and some must be secure, so introduce a locking mechanism. However, the lock may need to be disabled from one side all the time, such as when it’s an escape route. Frequently, the lock need not be keyed; a simple bolt or latch will suffice. The level of complexity in a lock usually indicates the necessary level of privacy, which often correlates with the strength and opacity of the materials used. However, there are some tiny, smelly rooms where a simple bolt lock or latch is sufficient, but they don’t suit Doors made of glass.

Mixed levels of security within a single Door exist. For example, you might like some things to pass through the Door without requiring permission, while others need the owner to unlock the Door. Examples include your mail or postal deliveries, which use letterboxes, or cats, which often don’t. You may also want to consider that even though you might not want someone to see through a Door, you may wish for light or air to pass through, so you can introduce a little window above the Doorway or just have the Door not sit snugly inside the Doorway, such as in restroom cubicles. Fitting letterboxes or cat-flaps to restroom Doors is not recommended.

In conclusion, the pattern of Doorway invites us to introduce a permanent hole into a wall when we seek a way to get from one room to another. We either frame it in such a way that you can tell it was not a construction accident or include a Door with or without a lock, made of a material appropriate for the level of privacy and security.

Hopefully, you at least found this funny, but do you see how it’s a description of doorways, and yet it’s not a pattern? Poor patterns often read like descriptions of the obvious. However, they carry lots of extra details to give it fullness. Here, we talk about doors and their many incarnations, but we don’t align motivation with resolution or consider the consequences for people’s lives. We never got any insight into why and when you would choose each type of variation.

When you look at the original work by Christopher Alexander, you won’t find the pattern of a door. Instead, you will find many patterns that include a door or a doorway as a required element for completion. The door may be described in those patterns, but it’s never the centre of the pattern. Even in the patterns 224 LOW DOORWAY and 237 SOLID DOORS WITH GLASS, it’s the lowness or light transfer that is essential, not the door. Otherwise, there would only be one pattern, indicating only one problem.

Some characteristics may be brought to attention, and some warnings may be laid out about decisions you might make, but there is no pattern of doors in general. Doors are components of patterns. They are the materials or elements of a configuration. Patterns are definitely not just better names for features; if they name anything, they name configurations.

All these details in the Doorway pattern add up to too much to look at. No wonder people can’t figure out what to do with patterns that include these highly detailed descriptions. When building a door for a car, why would you even consider a cat flap? Why would you wonder about whether it needs to be fireproof? There’s too much going on in this description, and yet, it’s also too terse. It’s too much and not enough at the same time. This is because Doorway isn’t authored in a way that benefits people.

Patterns are the identifiable steps you apply to solve the problem of how to build a thing, not the thing itself. This has been a constant problem. What they are is distinct from what you might look for. You look for an unknown but specific solution to a real problem you have but cannot fully describe. You want solutions to complications arising from situations, including information about what else to measure, verify, and evaluate. That’s where the benefit lies in pattern languages. They link together many patterns and expose problems previously unknown to their readers.

Looking for things by pattern names was always going to require more luck and effort than looking for them by context. It’s why we should never have based pattern names on their solutions. If we had identified them by the pain caused by the problem or easily perceivable elements of the problem, I might not have had a story to tell.

When you set out your patterns like the Doorway pattern, with all the possibilities, you end up suffering the same problem you have in overly generic code. Because you don’t have any basic assumptions, there will be too many contexts to find out what could be a nearby related problem. In software, this is especially true where things are so similar that you’ll find that almost every pattern is related to every other pattern until you start whittling down the number of contexts.

Consider a pattern of a stack. If you try to handle all the options, you will overwhelm the person trying to define it. You might have one particular stack in mind, so I will list a few so that you can imagine the breadth of content if you were to attempt to describe it in the manner of the Doorway pattern.

• An array and a head variable
• C++ stack container based on the std::deque class
• A linked list-based stack of objects
• A stack with varying sized elements, such as is used by the runtime in C and other stack-based languages
• An auxiliary structure to provide a stack-like interface to pre-existing objects

Documentation for a simple problem like this will explode in complexity for the reader if we fail to differentiate between the kind of stack used at the low level and the kind used at the language level. A lack of context or too many contexts diminishes the value of design patterns.

It’s easy to accidentally start adding corner cases, as options and flexibility are like catnip to programmers. Many otherwise compelling books on design patterns have made this mistake. Indeed, some solutions have many different possible uses. But because of this, when someone begins to document them as a pattern, they strive to find a generic form. Then, the resultant treatment fails to capture the value of each unique situation.

As a takeaway, think about patterns from their problem context alone, not from the point of view of what you should call a pattern solution or what other patterns are similar or related in how we categorise them. Naming patterns is only a worthwhile practice for conversations about pattern selection for a larger design. It would be preferable to name them by context alone, but those names are lengthy and complicated.

If we take the problem as the starting point, things improve. For most GoF book patterns, the problem was often related to coupling or lack of variability. That’s only two apparent patterns. The second is dealt with by nominalisation—the extraction of variability into an object. We could rewrite the GoF book into just three or four patterns, with many examples of how to use those patterns to provide solutions in different contexts.

This naming fault even exists in the works of Christopher Alexander. Some patterns in the original pattern book, A Pattern Language, have charming names describing what they are about and what they reinforce or create. 159 Light on two sides of every room is wholesome and reinforces the importance of diffuse light without ever literally demanding windows. But these names result in a quandary for those hunting down solutions to their problems. You can’t find them by these names. They’re lovely patterns, but it is necessary to read them to understand their value And you often only know their relevance after you have read them. Who would think that 159 Light on two sides of every room had any application to lighting an emotional scene in a film?

Context is a better basis for finding patterns when considering how we look for things when needed. You may wish to look for a real solution to a concrete problem you have right now. In this case, you can only use patterns if you already understand them or understand enough of them to know where to look. Finding the fix for your problem can be taxing if you’re unaware of the pattern that fits. What you have is information about the problem rather than the solution.

As a counterexample, when it comes to sorting algorithms, you know when you need one and where to look for it. You realise you need to regularly find something in your container based on some ordering of the set, or the items must be sorted for processing by a method outside your control. You are aware of your problem, and you know the type of solution to look for. You can do a web search for sorting algorithms, learn about the big O notation if you haven’t already, and then select an appropriate solution based on your expected data. You can either happily implement it yourself or use a library to solve your problem without doubting that the solution suits the job.

Sorting is a pattern, but we know it. We know the name but might not know the correct solution form, so we look up the pattern information (big O, time/space trade-offs, stability) and select a solution resolving our specific forces in the context of needing to sort.

Sorting is one of the many foundational subjects of programming literacy. When I was a child, I worked on a program on a ZXSpectrum in BASIC, and not knowing about route planning algorithms caused me to reach an impasse with my little game project. Lacking even the knowledge of what I was looking for stopped me from finding a solution. I didn’t know I needed a path-finding algorithm to solve my problem. I only knew I didn’t know which way the enemy robots should step to move towards me when I added obstacles to the world. Patterns are analogous to this. When you cannot clearly articulate your problem, finding the pattern to solve it is virtually impossible. We teach a broad range of algorithms in programming courses so you know the categories of problems you could face. You use them as a lexicon in your search for solutions.

Another time we don’t need to know the pattern names is when someone else does. Names worked out fine for Christopher Alexander because the way they worked included a phase in which they built up a smaller language to match the project they were working on. His team found the necessary patterns and presented just these few to the people involved in the process, just like Kent Beck and Ward Cunningham did for those novice developers in 1987[UPL87]. So, we need to add knowledge of patterns at an architectural and leadership level. The architect or lead can use patterns to help guide others to a better solution. However, this isn’t possible because of a problem: unavailability.

Unavailable

Design patterns are only available to some people. Yes, the GoF book[GoF94] is available to buy, and online videos cover most of their patterns in detail from multiple sources. But the greater scope of design patterns is not available. I need to explain a few things about availability, and I will start by explaining what it means to be unavailable for an individual. Here are some reasons why a pattern, even if you know the name, might not be available to you specifically:

• You cannot afford to buy the book in which it is found
• You are not fluent in the language the pattern is written in
• You learn best by video, but those available lack accuracy or credibility
• You can’t buy the book because it is out of print
• The library withdrew the book out of lack of interest, so borrowing it is impossible

If you don’t know the name of the pattern, it will be unavailable to you because:

• You’re unaware of other design pattern books, so you don’t know to look further
• You’re unaware of the relevant book, so you can’t discover the alternative pattern
• You cannot search for them anywhere to find an appropriate pattern for your unusual or niche problem

A source of information is unavailable to an individual when any of these reasons apply. You might want to learn, but the time investment in finding a good video series is daunting compared to a cheap book covering the essentials.

When researching for this book, I found Christopher Alexander’s works relatively easy to acquire. Most are still in print. Those that were not, were not too expensive to buy second-hand, except for one book[AFo21CA93] on Turkish rugs¹. But when it comes to books on software design patterns, many were out of print and only a few of the longest-lived titles were available.

Being out of print and unavailable in libraries is an underlying problem for the software design patterns movement. The lack of interest in the extended pattern collection reduced the print runs of books on the subject. The success of the GoF book perpetuates the printing of its first edition. This lopsided success causes us to see search results such as ‘there are 23 design patterns’ and receive hundreds of hits for videos explaining them as the design patterns of software development.

With so few people knowing how much information is out there and the information being so difficult to get hold of and varied in quality, you can understand why people don’t use these books as a reference more often.

I believe we need a place that contains many more of the patterns we know about. It needs to help people find patterns matching their contexts. I would suggest something dynamic so that we can maintain the patterns, as they need to be safe to use, and safety is relative. But each pattern needs to be organised by the problem a person has and where they have it, not stored according to the funny name for a clever solution some bright spark came up with one day and wanted to share with the world.

Unidentifiable

For patterns, there’s another twist to the problem with their findability. It’s not a real word, but I didn’t have to explain it to you for you to know it meant the same as discoverability. Well, that’s one of the problems with software design patterns. Even when you read or hear a pattern name, you cannot be sure you know what it pertains to. How can someone immediately deduce the meaning of even some of the best-named patterns, such as Factory Method or Template Method? These aren’t bad patterns because of their names, but the names are not helping. However, many patterns have even worse names. Few people understand the Interpreter pattern because it shares a name with another concept in computing.

Furthermore, references collide. All three variants of the Interpreter pattern sit under one name. Both interpretations of Adapter (class and object) are hidden under one pattern. Why?

The ambiguity we bring with overlapping terms is a significant problem with patterns, even when you know they exist. When you know a pattern could help you make decisions, it’s almost impossible to know what it might be called without knowing the name. The accepted categories of software patterns don’t improve things. I applaud the authors of Pattern-Oriented Software Architecture[POSA96] on their decision to categorise by what level of abstraction and what class of problem the pattern attempts to solve. The pattern hunter only needs to sift through a few patterns to see if there’s something applicable from those available at the architectural altitude they are designing for. But some offerings merely present a long list of patterns categorised by usage rather than by where and what they solve. These lists are not helpful, but it’s even worse in the case of a catalogue listing them by name or author. It’s as if there are no categories at all. It’s similar to a dictionary sorted by word length first (hmm, quite advantageous if you are playing a word game, I suppose, but not the right form for finding definitions) or by the order first seen in use. Actually, that last one sounds engaging, like a history of language one word at a time, but admittedly, again, not a convenient reference.

So, we end up with an extensive collection of patterns that could solve our problems if only we knew about them before we needed them. We need to know their names and roughly what they help with before we can properly look for them. It’s like we need to be vaccinated against the problems by reading the pattern books before we begin writing any code. I needed to know that route-planning algorithms existed before I could use one in my childhood game project. But there’s another problem when seeking solutions: problem visibility.

When it comes to sorting algorithms (again), you know whether or not you need to sort something. You can quickly tell you have a problem when the order is incorrect but you would prefer it sorted another way. When it comes to the problems design patterns usually help solve, sometimes the problems are invisible when they first appear. The vaccination comparison is even more pertinent in this case. A pattern often solves a problem lacking visibility until very late in development. In this case, we would never seek out the pattern. Avid pattern readers would only stumble upon it by accident, but that would be serendipity, not procedure. And even then, it would only be fully ingested and recalled when its specific situational applicability turns up if it piqued their interest. Consider how often people think to use the Flyweight pattern compared to how often it would be a useful refactoring. You frequently see complicated value objects in domain-driven design, and yet the Flyweight pattern is somehow overlooked as a solution because the problem isn’t made visible by how developers work.

Names inhibit the reach of a good pattern. When we label things, we constrain them by what we can conceive. We assume their title describes all they can solve and limits our imagination. In C++, the Iterator pattern is locked into the naming of the STL. When you get an iterator from a container, it is assumed you will use it to iterate over the container. This is fine if you are using the iterator for iteration, but the name leads many developers to ignore other uses of iterators in the language. In the case of vector, they indicate a piece of memory, so you can use them for much more. They can result from find operations, reinforced by their usage with map. Generally, however, they are overlooked for other purposes because they have this name, and the common attribute is that of iteration. If they were not named thus and instead given unique representations based on what they were, it could open the mind to different opportunities.

An example of the failure of patterns can be seen at the microscopic scale with the nodiscard keyword in C++. The nodiscard keyword provides a mechanism to raise a warning when you ignore a return value. It’s a solution for two different problems.

One is the problem of ambiguity in function names as to whether they are actions or queries. When the keyword was introduced, the standard was updated, and calls to empty on containers gained the tag. It protected users from ambiguity of intent. This is a problem we have with naming things. Should a function called reverse reverse the container in place or return a reversed copy of the container? Without looking at the documentation, it’s hard to know. The nodiscard attribute came to the rescue.

The other main reason for nodiscard was the criticality of responding to the result. Again, they added the attribute to standard library functions returning resources requiring management, such as memory allocations and thread creation. In other situations, discarding is dangerous, such as when you must act on the result. If you request a lock on a resource, such as a mutex, you should act differently depending on the outcome of attempting to take that lock.

There’s nothing wrong with having both variants use nodiscard, but the problem that is solved is different. In one case, you called the wrong function. In the other case, you called the correct function but did not handle it sufficiently. The const keyword nearly fulfils the demands of the first usage (it doesn’t for free-functions, but for methods, it almost works), but few compilers even emit a warning when you fail to use the return value of a const method. Without phenomena, the coder will continue to use the method ineffectively.

class A {
  public:
    int f() const {
        return 5;
    }
};

int main(int argc, char* []) {
    A a;
    a.f(); // this is almost certainly wrong.
    return argc * argc;
}

// Even with -Wall -Wextra -Wpedantic
// No warnings emitted by clang 16 or gcc 13.1

// snippet available at https://godbolt.org/z/TbnbvYPb5

Patterns can have similar overlaps. When they are solution-oriented, they can resolve more than one problem. Named this way, they’re hard to find, but even when you do find them, you may only have one problem variant in mind. So, you disregard them as a solution to your problem, even though they’re compatible.

Let’s return to the Interpreter pattern. Most developers think of it as a way to handle scripting languages. This understanding of the pattern stops developers from thinking about it as a solution to the problem of the interpretation of a structure. The way the GoF wrote about it, it’s hard to extract this buried variant unless you read the last part many times. They understood its power to manipulate structures but buried the lead. So, their examples looked like interpreters. Because the primary interpretation reflects a way to visit a structure to create some kind of result, and the result presented is not a compound in all but one example, we hardly ever recognise it as a pattern of structure updates.

When the Interpreter pattern was analysed, its repeated manifestations deserved more attention and should have been better dissected. Too many different contexts and forces were allowed in. There are multiple patterns here, but the way it was documented weakened it because it covered too much. Just like the Doorway pattern.

Unusable

And here we get to the final failing. All software design patterns have a problem caused by the structure of their presentation. They manage to neither provide education to beginners nor the ready reference of solutions they purport to be.

Beginners in a subject are unlikely to understand the contexts in which the pattern arises. Most patterns presented take little time to explain the context and forces because they are solutions first. But the trouble beginners have is often the need for more insight into what their problems are. This gap is the reason why design patterns remain both overused and underused by those new to programming.

A beginner needs hand-holding through specifics, and patterns aren’t about specifics. Someone picking up a design pattern needs counterexamples to know what a pattern does not warrant or require; otherwise, you end up with cargo cults.

But even when you are experienced, and even when you do know what pattern you are looking for, they can be difficult to use well. This is because, again, they are presented in the final form rather than as a process to reach it. Having a solution to review is inspirational rather than educational. Having a problem worked through is a much more powerful lesson. For experienced developers, a solution can be enough. But even for the most seasoned, if they are in a rush, it can be tiring to take on the additional cognitive load of converting it into a plan of action. The book Refactoring to Patterns[RtP04] addresses this specific point; nonetheless, all pattern descriptions should have included the before and after and a sequence of steps.

What were the original software design patterns documented for? One purpose may have been to show elegant final forms. This noble goal was likely the main driver behind the patterns in the GoF book[GoF94]. However, I strongly suspect many other patterns were documented, intentionally or innocently, as a form of self-promotion or plumage of developer prowess. We will see later how this ego-driven aspect is at the core of many pitfalls in design patterns, software and otherwise.

What Are Patterns Really?

Now we get to the deeper theory behind why things went as they did. The basis of many problems with software design patterns is rooted in how so many aren’t patterns at all. Before we attempt to analyse this impact, we need to be well-versed in how things could have been. We need a deeper understanding of what patterns are, what they are not, and how they surpass idioms and techniques.

This chapter will start with the idea of patterns as wisdom. Then, we move on to the form of a pattern—how it reflects its final state and the process by which it accomplishes the task. Patterns are actions, and their actions are always about resolving some forces in a context, so we continue with a section on what this means.

We can then talk about the importance of relationships. Patterns were born from the idea that relationships are the critical aspect of complex design. Without thinking about patterns as part of a larger intertwined configuration, much of their value is lost. We then move on to how these connections explain why they are eternal, not idiomatic or momentary. We conclude by analysing the claim they emerge without being designed with intellect, that is, they are most often found, not invented.

Wisdom, not solutions

If knowledge is knowing how to do something, wisdom is knowing what doesn’t work. Wisdom is experience-based, and the most persuasive experiences are negative feedback. In essence, being wise is learning your lessons and not making the same mistakes again. It doesn’t stop us from making new mistakes, but at least they’re new.

Design patterns are like that. They are often called recurring solutions to problems because they stipulate the invariants of any high-quality solution to a specific problem. Wisdom helps narrow down your options. X is impossible because of Y unless you have Z. These problem-specific constraints help guide someone to a solution. But they are not sufficient to generate a solution, only steer the process. That’s why patterns include examples—as inspiration for what you could do. There are some general motivations for deciding on solutions, such as:

Patterns have warnings in them. They are adaptable in relation to regularly neighbouring patterns. They have principles that have been revealed during many trials and many errors.

Initially, patterns emerged from trying to bring back a straightforward approach. Traditional methods were attractive because of their lack of apparent complexity. Their ability to locally adapt to environmental changes was an attractive feature for Christopher Alexander. But, when he analysed traditional methods in Notes on the Synthesis of Form[Notes64], he found situations in which they fell apart.

The Slovakian peasants used to be famous for the shawls they made. These shawls were wonderfully colored and patterned, woven of yarns which had been dipped in homemade dyes. Early in the twentieth century aniline dyes were made available to them. And at once the glory of the shawls was spoiled; they were now no longer delicate and subtle, but crude. This change cannot have come about because the new dyes were somehow inferior. They were as brilliant, and the variety of color was much greater than before. Yet somehow the new shawls turned out vulgar and uninteresting.

— Christopher Alexander, Notes on the Synthesis of Form, p. 53.

Traditional techniques were stable but had no insight. He couldn’t use them as they were. Tradition is wisdom without awareness. In contrast, intellectual design is awareness without wisdom. Awareness-driven decision-making is limited by mental capacity. These two contradictory solution methods contributed to an apparently unsolvable problem for designing complex forms in the modern world.

What Christopher Alexander wanted to do was create a solution to the two problems of modern buildings. He wished to resolve tradition’s inability to keep up with modern techniques and a rapidly changing environment—because tradition, for all its benefits, becomes ineffective when exposed to rapid progress. He also sought to solve the problem of modern architecture’s inability to handle the inherent complexity of building large, complex structures. After executing a plan from a modern process many worrisome stresses and tensions are left unresolved. Alexander needed a way to construct wisdom from thin air.

The outcome of Notes on the Synthesis of Form was the appearance of patterns. A way built upon understanding the categories of mistakes made by the modern process. A way to reveal new traditions by calculation and intellectual processes. Patterns were discovered wisdom because the mistakes modern architecture was predisposed to making, the things you ought not do, were almost always about unexpected negatively consequential relationships between elements, that is, relationships where changes to improve one part degrade another.

Instead of tackling the problem of complexity head-on, he concentrated his efforts on the category of mistakes. The approach centred on architectural elements from the point of view of relationships of change, focusing on changes affecting multiple elements in opposing ways.

The natural way to decompose a system is by what you know, things you already have names for. In Notes on the Synthesis of Form (p. 127.) Christopher Alexander suggested that when diagramming the decompositions, you should ‘resist the temptation’ to use ‘well-known verbal concepts’ for the new change-connected chunks but instead diagram them so that they don’t lose their power under the influence of pre-existing biases. The reason precedes it: each diagram or name must be both complete and unadorned with any accidental requirements caused by ambiguity or prejudice.

By starting from this different position, he found a way to elicit wisdom from the context and the forces at play. Collecting elements by their impact on each other was one part; how they affected and revealed otherwise unseen compounds made manifest only by the relationships between elements was another unexpected important discovery. These implicit compounds were the first sighting of patterns. They sprang forth from the contexts and forces and were the foundation of the new way of thinking about building.

Without a surrounding context upon which to pivot, and without forces to guide its necessity, a pattern will not emerge. There can be no mistakes if there is no will to induce change. There can be no mistakes if there is no context by which to judge the decision. These points are why most true patterns are wisdom. They contain the impact of mistakes such that they will not be made again.

When you think of patterns as solutions to recurring problems, there’s a problem. They aren’t solutions; instead, they are how any viable solution can be safely reached and verified. When well presented, they capture common structure, behaviour, and control flow in particular domains of any good and valid solution. They’re not so much about capturing the details of solutions already seen but revealing all the regrets you could have had if you hadn’t abided by the restrictions and limitations found by those who walked the path before you.

Good pattern definitions should contain restrictions and limitations guided by positive aspects presented as principles of a high-quality final form. They can be lists of things you would be unhappy about if you hadn’t considered them. Not so much how to do it, but more the kind of story that starts, ‘We know what you’re gonna try to do, so here’s what you need to look at’. In effect, patterns must be stories of your future. Someone else has already gone down your route. They are reporting from your possible future about your plans and how they worked out—even though you haven’t yet taken the first step.

And because they are wisdom, patterns are never about cool ideas. They are always the wisdom captured by others who went through similar situations. Tales told about what happens when you live through it. They’re distilled anecdotes. They’re wisdom. They’re warnings.

Again, patterns aren’t solutions. The solution is usually pretty obvious, but it has to be coached out of you by giving you the right questions. Unfortunately, given the present form, you have to know what the solution entails before finding the ideal pattern to consult. But when you’ve located the pattern, you can use it to better understand your problem and uncover other snags and consequences you hadn’t yet noticed. What else about your solution aren’t you considering? A pattern helps you change your mind. You can be rewarded by learning new constraints, which inspire new opportunities.

Patterns aren’t tools for construction. They’re a way to organise how to use your tools. They’re not reusable techniques for software design as in the verb ‘to design’. They’re reusable wisdom of systems that spring into life around a solution. They provide insight into maintainability, as well as what solution system pairings might look like and their respective consequences.

Innovative patterns

However, not all design patterns seem like wisdom. They might appear to be inventions at first sight, something you wouldn’t easily come across. These patterns are epiphanies, but they are regularly self-forming. They are the inevitable inventions of people put in a context with certain forces. You might wish to think of them as belonging to a slightly different category because they take an inspired leap. They’re not the patterns of trial and error; they’re inventions with some insight and higher thought.

Invention patterns include the use of fire and the bow and arrow. We invented weaving, rope, knots, and sewing many times over. Mathematics and logic emerged from contemplation alone at many points in space and time. These aren’t quite natural patterns, because they need thought to bring into being, but they keep emerging anyway. We refer to them as patterns because they also resolve forces in contexts, but these are the patterns that are often structured solutions. They include a lot more ‘do this’ than ‘avoid that’.

These patterns can appear in nature. Examples such as the eye with a lens to focus might seem like a leap from the pinhole. We know nature doesn’t think, so it’s clear these clever solutions can emerge without thought.

There are fewer invention-type patterns in Christopher Alexander’s work, but they are present, such as 251 Different Chairs or 229 Duct Space. Their presence may have contributed to misunderstanding the purer form of complexity-dissolving, wisdom-based patterns. The inventive patterns are more immediately attractive to programmer types and lovers of puzzles.

Indeed, in pattern literature, it becomes undeniable the more you read about them outside of software development: design patterns don’t stop you from having to think. Instead, they invite you to think more acutely. They give you the inspiration and context to understand what to think about.

A process and a thing

Christopher Alexander did not consider a building as finished so much as being an attempt, an approximation of an unattainable perfection[TTWoB79]. Every building had an age and a state of repair. The older a building became, the more likely it needed small repairs or an extension to match its new usage. But, for him, even a new but incomplete building was in a state of repair.

Rigid building designs are brittle and not very likely to survive changing times. They don’t allow for adaptation. Most modern buildings are like this. Consider the different physical space and connectivity needs of offices over the last few decades. In contrast, there was a suppleness to all of Christopher Alexander’s designs. He built each building, component, extension, or improvement so they sat comfortably with what was already there and remained conscious of the need to support an unseen future, greater form.

The same value in malleability can be said of code. Old code is only good if it can be repaired when it is no longer fit for purpose. Christopher Alexander wrote[NoO1-01] negatively about buildings with no scope for extension or capacity to adapt. Compositions that can only be put back into their final state were not living but were arrangements brought into existence by a dead process.

… 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.

— Christopher Alexander, A Pattern Language[APL77], p. xiii.

If code cannot be changed, it’s not good code. If you can only make it work by shoring it up so it does not need to change while everything else works around its failings, then it’s still not good code. More to the point, it was never good code.

Patterns are about solving a problem, but they also contain the process of achieving a solution. As with wisdom, we see a reason behind this. Complex things built through traditional methods were always constructed piece-wise. No successful, large, complex thing was ever made in one step. My feelings resonated with the words of John Gall when I read:

A COMPLEX SYSTEM THAT WORKS IS INVARIABLY FOUND TO HAVE EVOLVED FROM A SIMPLE SYSTEM THAT WORKED.

The parallel proposition also appears to be true:

A COMPLEX SYSTEM DESIGNED FROM SCRATCH NEVER WORKS AND CANNOT BE PATCHED UP TO MAKE IT WORK. YOU HAVE TO START OVER, BEGINNING WITH A WORKING SIMPLE SYSTEM.

— John Gall, The Systems Bible[SysBible02], p. 63.

Complex things at scale are only successfully made with traditional methods when built piece by piece. Because steps are required to build well, patterns must also be processes. They are the wise steps to take to achieve a new, better state, with each state being a distinct solution to an expanding problem.

The thing aspect of this has to do with an essential completeness of all patterns. A whole thing in one notable entity means the pattern describes a complete system of elements supporting each other. The system can be tiny, but it has to be complete and self-supporting. As an example, by negation, we can take an element away. The pattern of 105 South facing outdoors from A Pattern Language[APL77] is a good quality pattern of reserving the best light of the sun for the outdoors of a building plot by giving it the south (or north, in the southern hemisphere) of the land. This pattern consists of only the land and the building. By removing the building from the pattern, it has no meaning. By adding neighbouring buildings, it gains additional but worthless complications. The point is to make sitting outside by the focal building a positive experience. Sitting on a plot by a neighbour’s wall is not relevant to the goodness and wholeness of the construction.

Wholeness means a whole thing in one entity and repairing it to a wholesome state. At each step, the entire thing is good—or at least not worse than before. The south-facing wall has a usable seat, for example. And when we see something as incomplete, it’s not healthy. It needs repair. If we plan to add a shape to the building but it would introduce a shadow to the outdoors, we can recognise that and adjust the plan to fix it before it happens, just as tests tell us our proposed change is not good.

Many things will be unstable when we work on a project, but we can decide to work on those tasks that close the most significant gaps. We can look at the needs of the whole project and tackle the highest-impact decisions first. This way, we start with nothing and repair the project into something we are happy with. At each stage, we make it better, more alive, more whole.

Even though design patterns are processes, they regularly explain themselves by describing an outcome. The manipulations we need to apply to get to that outcome from our existing context would be much more helpful documentation. We can look at how a building plot turns into a building over time with design patterns. Residents change. Their needs change as they go through stages of life, both temporary and enduring. The building will no longer be a perfect fit for their changed needs. New patterns will become appropriate as new forces appear, so the building should be repaired into a new state. In software, we see this with changes caused by revelation or modifications required to meet new expectations of users becoming accustomed to features available in other, related software.

At the detail level, we may migrate to using a Strategy where we previously had a direct function call. A recent additional requirement, the need to configure which function we call, would be a new tension needing repair. Perhaps a switch isn’t powerful, extensible, or safe enough for our latest use case. We need a variable to store the action and a way to inspect or serialise it, so a simple functor will not do.

The context for the Strategy example is a behaviour invoked at a certain point in time. The forces are our need to adjust the behaviour at runtime. So, we observe a new variance. In some languages, such as Python, support for this is built in. But when using C++ as an object-oriented language, we need to use something to let us bind to a function at runtime. To do that, we can take the step of nominalisation: converting a verb to a noun. This step is the process part of the process and a thing.

The nominalisation step is the transformation—the change we wish to make to the environment to fix it. It is a process of repair.

Taking the plot of land for a house in the northern hemisphere and splitting it such that the house is at the north end so the south-facing wall can have a semi-private, well-lit open area around it is also a process of repair to the current design. It is the right step to take:

• for the purpose of the land
• in the context of benefiting from good light when outside the property but still on the land beside the property
• to use the land well, to its fullest
• for a northern hemisphere property

Given context and forces, nominalising a function into an object can be the right step. The Strategy pattern describes the process for when you want to solve, for some constraints, the capacity to adjust which function is called without having to go into the existing code again.

The Strategy pattern is the application of a sequence of steps to get to a solution for a problem in a context. It’s why we can still use it in languages like JavaScript, where you can put a function in a variable or override any class methods whenever you feel like it. All prototype languages can use the Strategy pattern because it’s not just the final object-oriented form but an idea of allowing for dynamic behaviour based on state. The concept was limited to object-oriented programming because of the aims of the book in which we find it. The pattern was defined as a way to store functions in objects but, at the core, it’s just runtime dynamic behaviour.

Because the code used by the authors at the time did not have the sophisticated mechanisms available to modern languages, they did not recognise the pattern for what it was. In effect, the Strategy pattern could be interpreted as Last Minute Decision Making. It allows for a function to respond to an event, but the responding function can be decided upon at runtime. It’s a form of dispatch mechanism, so comes with all the related downsides. The problem with not understanding the problem or process driving the pattern is that when new solutions come along, you don’t replace the old inferior solutions in your pattern definitions.

Some people use Strategy or policy objects in languages where they don’t need to, just because they are now the solution accepted by the culture. They have drifted into being an idiom. If you need to call a different method based on some configuration in Python, you can do this:

class MyClass:
    #...
    def configure(self, new_strategy):
        self.do_it = new_strategy

    def do_thing(self):
        self.do_it(self.context_a, self.context_b)

And if you are using C++11 or beyond, you can do this,

class MyClass {
    public:
        using Func=std::function<void(const TypeA&, const TypeB&)>;

        void configure(Func new_strategy) {
            m_do_it = new_strategy;
        }
        void do_thing() const {
            m_do_it(m_contextA, m_contextB);
        }
    private:
        Func m_do_it;
};
Snippet link: https://godbolt.org/z/rd41o1ssT

And even if you are using a language without these features, there are still workable solutions. You can achieve it in C, which almost proves this was never an object-oriented pattern in the first place.

struct MyStruct {
    void(*do_it)(int, int);
    int m_contextA;
    int m_contextB;
};
void configure(MyStruct *ms, void(*new_strategy)(int, int)) {
    ms->do_it = new_strategy;
}
void do_thing(MyStruct *ms) {
    ms->do_it(ms->m_contextA, ms->m_contextB);
}
Snippet link: https://godbolt.org/z/MfMoxTh5T

So, the essence of the pattern (introduce a family of algorithms that can be selected from at runtime) is maintained in these examples, even though each of these implementations is utterly different from anything in the GoF book.

Generative, not descriptive

In the whole body of Christopher Alexander’s work, the slide towards generative processes is gradual but unmistakable. In The Nature of Order, Book 2[NoO2-02], the generative process takes centre stage, binding to the core argument from the first book with great strength. However, even in his early works, his theories seem based on an epiphany over the difference between traditional methods and those of modern architecture.

The architectural theories at the time were descriptive, not prescriptive[Grabow83]. There were very few rules on how to design a building. Mostly, they were rules on how to review a building once constructed. Buildings tended to be similar to those around them out of actively planned consistency rather than because they followed a generative process. The prescriptive rules were all in the domain of engineering. Only the engineers had rules for weights, ratios, and material limits to drive their decisions on what and how to build.

At the beginning of his work, Christopher Alexander suspected this was the cause of the problems in modern architecture; hence, he looked to traditional building processes to find a way to extract this generative nature. However, it would seem Peter Eisenman found the descriptive architecture thesis quite alarming. Eisenman became an internationally acclaimed architect later in life, known for projects such as the Memorial to the Murdered Jews of Europe and the Wexner Center for the Arts. His style is most certainly what one would call modern architecture.

Eisenman countered Christopher Alexander’s work with his theory of modern architecture[Formal63] in 1963, even before Notes on the Synthesis of Form[Notes64] was officially released. When understood, Eisenman’s thesis pushes back against Christopher Alexander’s unspoken complaint that modern architecture was not a generative process and thus was devoid of humanity.

However, even though Eisenman’s thesis argues against Alexander’s implicit conclusion, making it clear Eisenman holds that modern architecture is, in fact, a prescriptive and generative process, it does not quite hit the nail squarely on the head. He side-steps the question of humanity completely, preferring to generate forms with which to achieve artistic meaning, or even no meaning at all.

You can see evidence of Eisenman’s values in his later works. There are often clear signs of a desire to design for the sake of the piece’s meaning. Meaning drives form over value to the people who would use or inhabit his buildings. I see parallels with the architect Corbusier, with his artistically advanced but practically unsound Villa Savoye and the thankfully unrealised Ville Radieuse (Radiant City). Eisenman’s split bedroom¹ in House VI is one example of thrusting his intent onto the inhabitants of the building. Another issue with that house is the strange staircase lacking any handrail. As someone who enjoys good design, the quote by Dieter Rams (the famous designer of many Braun products) comes to mind:

Indifference towards people and the reality in which they live is actually the one and only cardinal sin in design

— Dieter Rams²

The problem behind both (Alexander’s and Eisenman’s) arguments is not whether modern architecture was generative but, more critically, what was generating it. This is an important distinction we will go into later. For now, we can take it that both aspects were true. Architects acted as Christopher Alexander proclaimed, actively designing without using a generative process tuned for human values. But Peter Eisenman’s thesis was valid in claiming modern architecture used a generative process.

What interests us is how we ended up with descriptive, not generative, software design patterns. They often describe what was achieved, not how to decide what to do or how to get there. When you want to implement a sorting algorithm, you use the instructions for implementing a specific one. That’s a description of an existing solution; a solution you take and apply to your language. A generative process wouldn’t have a particular solution in mind but would give you the steps to reach a valid resolution of your situation. It would have metrics or rules to verify the solution should hold under routine use.

If someone explains how to write a run-length encoder, that would be a descriptive pattern. It describes a solution you can use in quite a few cases but not how to invent a compression algorithm. But if someone explains information theory to you with examples, showing you how to look for the deeper information in your data and deciding how to encode it, that’s a generative process.

It’s worth noting that science is predominantly generative. The rules of physics, as they are known, allow you to figure out what to do when you try to produce a result. Imagine electrical circuits built by chance and hoping they will work out. Trying to mix chemicals to create new ones without the generative theory behind it is called alchemy, not chemistry. But art forms, too, can have generative rules. The layout of a good photo is reasonably well-known. Colour theory helps direct fine art. Understanding the effect of lighting on a scene improves clarity and can be used to evoke a mood, transferring emotions.

When art forms provide the rules of creation and let you work within them to forge something of value, you are freed by the constraints to concentrate on what you need to do to express yourself fully. This truism appears to have gone unnoticed by the architects who fought against Christopher Alexander’s work.

Patterns were meant to be a set of rules or guidelines on what to think about and when. They were to be used, in sequence, by people when constructing their homes and businesses to generate a good feeling and wholesome building. Patterns were intended to be generative. They are the rules or fabric of construction. They are the material with which we collaborate.

The artist, architect, or director is still the creator when they abide by well-understood patterns. Information, and therefore art and meaning, is the perceptible deviation from expectation. It’s an inspired choice or arrangement of already accepted structures. It’s not the presence of wacky elements (which Alexander called ‘Funky’ design[NoO2-02]) or taking things away without reason (which creates tension by their absence), but the meaningful expression through appropriate selection.

We should follow the patterns chosen by one in the know. Design patterns endow more to those who recognise new ones or see their essence. Those who can perceive new patterns from the random interaction of those building or creating we call the creators of new rules and a new, larger, more powerful language. They didn’t create, though, they saw. They had the acute vision to recognise something coming alive.

Generative processes are extremely important when creating anything of sufficient size. Without patterns, it leads to decision-making from a distance. This is sterile, wasteful, and ultimately alienating to those involved in the construction. Christopher Alexander himself said this from a different perspective:

ALL the well ordered complex systems we know in the world, all those anyway that we view as highly successful, are GENERATED structures, not fabricated structures.

— Christopher Alexander, The Nature of Order, Book 2[NoO2-02], p. 180.

Not just large but all successful, complex, well-ordered systems must be generated. A successful complex system in systems theory is found to only exist if grown from a smaller successful complex system. Success is never all at once. If we build a large complex system in one go, it will invariably fail to do what the designer intended. It will do something, and it might be hard to stop it. Just like a wish from a genie, it will do what you asked, not what you meant. So, we should never create large complex systems wholesale. Always build them out of smaller, successful systems. We must allow the smaller systems to combine and generate their way into larger systems.

About resolving forces in a context

A pattern begins with the context and the forces and only then starts to show its value through the constraints of a solution that satisfies them. Contexts don’t always have the same solution when the forces at play differ, and forces don’t always lead to the same solution when operating in different contexts.

Forces are needs, desires, and requirements. Sometimes, a stakeholder’s values impart a force upon a situation. Forces are the stresses and pains of the participants in the environment. They are the drivers of action and the cause of any imbalance. They are the unresolved conflicts or dependencies. In this, patterns rely upon and resolve the relationships between the identifiable parts of a context.

Context is the environment. It’s the situation in which these forces are playing out. It can include a project, the timescale of a solution, or other external limitations. It can be the available actions, such as tools and the principles to which a solution must adhere. In effect, the context is the sum of the rules of physics governing what is possible. It is the set of rules by which you may introduce change.

So, a pattern is a recognition of a set of forces in a context and the steps and techniques leading to solutions balancing those forces. Not a solution, but a guide to reach one. The patterns in A Pattern Language are almost all guidelines referencing things to look out for. They spend as much time on the motivation as they do on the suggested steps. Very few are explicit about what to do but will give limits and contextual metrics for a successfully implemented solution. This is in stark contrast to the patterns in almost all books on software design, which regularly offer a solution or three to show how you can do it but do not so much show you the way to reason yourself towards a solution of your own.

Not all books are like this though. One book I read on compression when I first started out in computer games fed me a diet of information theory and examples. I learned how you might exploit your domain knowledge to reduce the number of bits required to store your data. I internalised much of this wisdom and often view problems through its lens, and not just problems of compression.

Some building patterns are only appropriate within a culture or a climate. In software development, it’s the same. Consider which patterns only matter because of the medium, such as the language. A C++ pattern might be a language feature in Python. A pattern in C might be impossible to implement in Java or Rust. Consider also the applicability of patterns at different scales of each aspect. Does team size or product scale affect which patterns are valuable or available to the project? Does a quality bar or expected product lifetime affect whether safety-related patterns apply? Is maintainability or project budget more important than time to market? Some higher-level patterns resolve some of these forces over others. These are all part of the context.

The patterns of building construction don’t define what a place or thing is made of; instead, they define what kinds of affordances it has to the inhabitants—the actions and interactions that can take place in it.

The design of a spade does not specify metal or wood but a light shaft and harder than the target material blade. It includes size and proportion limits balanced against leverage requirements for a specific user and the target’s toughness. It’s relative; it’s about relationships between elements, constraints, and context. It’s all about how we will be using the tool, the contexts of dirt and available manual labour, and the forces of needing to move material from one place to another with a delicate touch. This is a pattern resolving forces.

When you think in terms of lawns, walls, paths, and trees, these are the pieces by which we complete the pattern. If you instead turn to the interpretation of things as relationships, such as a sunny place where you can be with trees, a terrace on the street, or a garden wall, they are about how things interact to produce something more meaningful. These are the forces. They are what it is for. People’s impressions of a place aren’t descriptions; they are the hopes. And hope is a force.

We should always consider design patterns superior to solutions because they are transformations rather than additions. They do not conflict with other patterns because they preserve and define, not replace or subtract. Why this is so will be explained in the chapter Fundamental Properties.

A language, a hierarchy, a web

This is often the most difficult aspect to comprehend. A pattern is part of a language. What the language is, is of secondary relevance to this fact, but I will cover both. The vital part of this claim is that patterns are part of a structured form with rules and meaning.

Each pattern in a pattern language is a compilation of wisdom for creating a local solution in a context, resolving forces. The context is only sometimes a set of concrete recognisable elements. More often than not, other patterns provide the context. Patterns are hierarchical, but they are also a web or, as said in A City is not a Tree ¹[ACinaT65], a semi-lattice. The top-level patterns rely on uncovering a configuration of subordinate patterns that satisfy them. The lower-level patterns need to serve both their neighbours and their parents. A Pattern Language[APL77] provided a set of interconnected, hierarchical patterns that could build a shed, a village, or something as large as a country.

Perhaps this sounds contradictory to the earlier statements of patterns being non-conflicting. Why would a pattern rely on a particular configuration if conflict was already avoided? Well, it’s because patterns do not cause conflict; they resolve conflict and maintain harmony in a system as it grows. But in an existing system with conflict, you must find and map patterns to the present structure. It is the existing discord that requires us to seek a path back to a good configuration. In a generative process, you don’t need to locate these patterns, as they emerge of their own accord. How this happens will be covered further in the chapter Fundamental Properties

We only see the beginnings of these kinds of interconnected hierarchical patterns in Pattern-Oriented Software Architecture[POSA96] and Patterns of Enterprise Application Architecture[PoEAA03]. These books concern themselves with the construction of applications, not just solving code riddles. There are no higher-level or lower-level abstraction patterns in the GoF book[GoF94], and only a few patterns refer to each other as neighbours (such as Interpreter referring to Composite and Visitor). They don’t tie code together as much as they should or talk enough about the adjacency of other patterns. When each pattern is independent of all others, it’s not a language but a menu. When patterns are strongly coupled, you are unlikely to use one without the other, and the tapestry is missing. Patterns are interlinked but not so tightly coupled they cannot exist without specific others.

Each pattern then, depends both on the smaller patterns it contains, and on the larger patterns within which it is contained.

— Christopher Alexander, The Timeless Way of Building[TTWoB79], p. 312.

Again, this might seem somewhat contradictory to the hierarchies of patterns. But let’s step back and see. Patterns are about resolving forces, most often of the needs of the inhabitants of the environment. That environment is the context, often resulting from the application of a higher-level pattern. But it’s not an element of the higher-level pattern. It’s an element of the realisation of a solution within the constraints of the higher-level pattern.

Each one is incomplete, and needs the context of the others, to make sense.

— Christopher Alexander, The Timeless Way of Building[TTWoB79], p. 312.

The higher-level patterns often provide guards against creating unresolvable forces in terminally conflicted contexts. This is why, even though a higher-level pattern might ask for 159 Light on two sides of every room, the sub-patterns could be to do with depth of windowsill (to allow sitting in the window to some extent referenced in 202 Built-in seats and 222 Low sill) or the spacing of pillars on a non-wall, such as is seen in 119 Arcades and 226 Column place. The specific sub-patterns must be selected only after the new contexts have been tentatively accepted. This way, even though patterns depend on each other, they are not coupled. They are given relevance by how they relate.

In this network, the links between the patterns are almost as much a part of the language as the patterns themselves.

— Christopher Alexander, The Timeless Way of Building[TTWoB79], p. 314.

It is indeed, the structure of the network which makes sense of individual patterns, because it anchors them, and helps make them complete.

Each pattern is modified by its position in the language as a whole: according to the links which form the language.

— Christopher Alexander, The Timeless Way of Building[TTWoB79], p. 315.

To be understood

In Christopher Alexander’s work, the call for a pattern language was to provide non-architects with the necessary words to design their own spaces. The hope was that a language was all that was necessary to produce functional, beautiful buildings. The GoF book doesn’t claim to be a language in this sense, suggesting itself that it is not a language by which entire applications could be developed². It recognises how patterns were seen in architecture but claims only to use the elements of forces and the way the patterns were captured. They miss the dual nature of the term language and downplay the benefits they provide.

It’s the naming aspect that succeeded in software design patterns. There is value in being understood, and Domain Driven Design[DDD04] made Ubiquitous Language a central theme throughout, from the higher-level design to the detailed implementation. Named design patterns allow us to speak to others in shorthand. Not all usefully named things are design patterns, and not all patterns have clear names. But design patterns let us think about pieces of a larger project by defining these ephemeral elements and their boundaries. So, even if they have poorly chosen names, as long as we agree upon those choices, it’s better than if we had not named them at all.

Clarity and hidden languages

Outside of the immediate value in the correctness of code, there’s also maintainability and the ability to talk about features we don’t yet have. The common language element of design patterns is brought up at the beginning of the GoF book, but it’s not explained in detail. In software, words are the elements we can use to build up towards a solution. They can be small or large words. We have low-level words such as lists, trees, and files; mid-level words such as message-bus, protocol, and connection; and feature-level words that are more domain-specific, such as account, inventory, molecule, page, and puzzle. But not all words are nouns. We have transactions and deletions, creation and modification. We have calculation and verification and more. All these words are literal because they exist in the code in the language used during interpretation or compilation. When we all agree on these words, and they match the non-code design and the elements of the world, we start to call them a ubiquitous language.

Guy Steele once gave a talk³ on how programming languages can be large or small. He explained how building up a larger language inside a smaller one is a way to make the language successful and how the ability to add new words provides a place for a community to grow the language into a larger one in practice. In his talk, he indicated that defining a common vocabulary in any source code makes it a larger language and that a larger language is always necessary to construct larger projects.

The existing software design patterns can provide standard terms people can use to comprehend a system. They give names to the organisation of the words without being present (you don’t call your factory pattern implementation RequestProcessorFactoryFactory⁴.) They provide a way to discuss how the parts work together and how the structure affects that. These meta words allow people to suggest future changes, even if they were not part of the community that built it.

All this means there is the language in which you program: C, Python, Assembly, JavaScript, Rust, or Java. There can be a language one step up, which includes the standard library; this sets the tone for later layers or provides seeds for the formation of the crystals of idioms.

There is also the language in which you write higher-level code built from the small words in the lower-level language. At this level, we’re talking about frameworks for writing larger things. Examples can be found with Express for JavaScript as a set of ways in which things are worded and grammatically combined, which are definitely not required by JavaScript but are required by Express. Game engines are frequently quite strict on how you code for them, and developing against the language rather than with it will lead to poor performance and problems that are difficult to debug.

In Express, Django, Rails, and Unreal Engine, there are core languages. Your framework might use Rust, Haskell, C, or Java, but you can’t just begin programming in a framework by understanding the language in which it is written. Each will have its own set of unique words and grammar.

Beyond the framework language, there will be the language of the project: terms specific but ubiquitous to your application or the team developing it. These will usually be idioms or idiomatic uses of patterns. All these layers need names for their content. Pattern names are just one of many ways to communicate how things are and how they could be.

Disloyal

There’s another kind of pattern. It’s the type of pattern everyone recognises and puts on the naughty list. These are the anti-patterns. The only difference between them and other patterns is that they hurt rather than help you. Anti-patterns are natural patterns that cause you problems. It’s helpful to recognise them quickly and find details on an alternative, a replacement pattern you want to use, or at least a method by which to extract yourself from the anti-pattern. If regular design patterns are wisdom, and wisdom is what you should avoid doing, anti-patterns are the design patterns of what makes sense at the time but you really shouldn’t do.

There are other sub-categories on the negative continuum. From patterns that are good but have some warnings to those that aren’t self-forming, but we genuinely want them to be. This is why I use the term disloyal. Patterns don’t care about humans, buildings, code, or customers. They just exist. Sometimes, they hurt by design; sometimes, they are extremely rewarding in a bad way, like chocolate cake.

The pattern of building large sweeping corners to reduce the chance of clipping the curb causes fewer bent wheel rims. But it increases pedestrian fatalities because visibility drops, time to cross lengthens, and cornering speeds increase. The pattern was self-reinforcing and self-forming, but ultimately, it’s an anti-pattern.

The pattern of building more auto-complete technology into IDEs is an obvious benefit to people wanting to code faster without looking up the API. But it comes at the cost of a shallow understanding of APIs and the increasing length of names without an equal increase in clarity of meaning.

The point is that patterns exist whether you benefit from them or not. Making anti-patterns visible is the first step to undoing any damage they cause.

Emergent, not idiomatic

When asked for a one-sentence characterisation of a pattern, I will usually reel off something like: ‘A pattern is a self-reinforcing configuration formed as a response to a set of forces in a context, whether for ill or good’. The word solution is absent, and I call out how the final form is not necessarily advantageous for those involved. These are important distinctions because so much of the design pattern movement has hinged on them all being solutions of some form, and little is understood about their effects on the health of their hosts.

The aspect of patterns always being positive is something that people might take for granted. Patterns aren’t good; they are just that self-forming, self-reinforcing aspect. Otherwise, we wouldn’t have anti-patterns. Or, at least not in the form I think of them now.

Notably, the value of a pattern can change over time, just as a species can be effective in one environment and mediocre in another. A pattern can be healthy in one context and unhealthy in another. The only constant is their self-forming, self-reinforcing, or autopoietic nature in the presence of forces in a context.

This emergent nature is not only fundamental to them not being idiomatic but also part of the verification process carried out by Christopher Alexander. Good patterns emerge. You find them by looking for how to resolve forces. When you successfully resolve them in a context for the first time, you often find a pattern has been staring you in the face throughout your endeavour. You may also find you have reinvented something. This is because common problems, when resolved fully, tend to have solutions with lots of common properties. And that’s the essence of a design pattern.

A pattern recurs because of the common properties of a problem. But some problems seem vague. Others only require those involved to agree. Here, an idiom suffices, something we accept as true. It is not self-forming or naturally occurring, but forming an agreement is natural. Idioms are always the things we have to agree on to make progress because a wrong answer is difficult to judge. They can often be completely unfalsifiable, such as the tabs vs. spaces arguments or bracing style wars.

Idioms contain inertia. Patterns, being emergent, collapse when the situation changes. Some idioms fight back. They don’t allow themselves to change in response to new data. They repeat again and again the same not quite right solution. They are a cultural phenomenon. An idiom is a convention. Conventions are difficult to repair, as there’s usually a lot of personal investment and apparent value built on these imperfect foundations.

Patterns emerge by themselves; we agree upon idioms. Because of this, idioms are less likely to be detrimental when they first arrive. We judged, balanced, and consciously accepted our idioms at some point. Patterns result from forces, and the solution gravity well forms around what resolves them. But that means the solution does not need to be judged by anyone before it becomes the norm.

In effect, anti-patterns exist because they satisfy the pattern, not the entities involved. The entities involved might have opinions about the solution’s value, but that’s a different context from that of the pattern. This means that a pattern can become an anti-pattern, and an anti-pattern can become a pattern when we judge it from a different context.

Found, not invented

In The Oregon Experiment[TOE75], Christopher Alexander reiterates what he means by patterns. He adds some nuance to the term and captures more of the value in the context.

With this in mind, we may define a pattern as any general planning principle, which states a clear problem that may occur repeatedly in the environment, states the range of contexts in which this problem will occur, and gives the general features required by all buildings or plans which solve this problem.

— Christopher Alexander, The Oregon Experiment[TOE75], pp. 101–102.

Notice how he claims a pattern states some invariants of a solution. The definition provided here is different because it does not specify the features of the solution to a problem but instead specifies the features of any solution to a clear problem. This indicates many possible solutions. The phrasing guides us to expect a list of criteria any good solution must have. It also points out that our problems need to be clearly defined. Part of the work of the ‘forces’ definition is to provide details on the problem’s root cause.

This is why it’s important to find patterns rather than invent them. An invention is a solution to a problem. Patterns are about solutions to recurring problems, which means you can’t invent a pattern, as you don’t have the same problem over and over again. You solve it once given the problem you face. You solve the same problem the next time by adjusting your solution. This means one person can’t realistically find patterns from their own work. They are inherently unable to verify whether the emergence of the solution is recurrent. It’s possible this nullifies many patterns that claim to have three instances, as the cases might be sequential and not distinct.

This denial of invention was officially recognised by the pattern movement, if not practically carried out.

[…] one thing that has distinguished the patterns community has been its aggressive disregard for originality.

— Brian Foote, Pattern Languages of Program Design 3[PLoPD3-97], p. x.

The later books hold up in that they are better curated and contain more patterns of the found variety. But why was it essential to make this statement in the first place? I suppose it was because some community members realised this was a systemic problem hurting the movement. What’s strange to me is how the pattern movement was so strongly related to systems theory, yet it took that long to realise the need to fight back against this detrimental feedback loop.

However, some patterns do feel like inventions: mathematics, bows and arrows, weaving, and the eye. They don’t seem to emerge from the forces naturally. As mentioned, these are complicated solutions, like epiphanies or inventions. But they keep occurring over and over. This is because when you have a set of forces and people working in them, trying to resolve them, or even natural processes such as natural selection, a solution will be attractive, even if it’s not obvious to those absent at the moment of invention.

These inevitable inventions are evocative of pits in a training landscape for AI, where this good fit has little to no gradient towards it. Nonetheless, the solution is a strong attractor around this inconspicuous local minimum. A tiny divot of success.

How Systems Theory Applies

Systems theory is the study of dynamic relationships, of how systems react and their emergent behaviour. It explains how they form and how they fight back against unwanted changes. Systems have senses, reactions, and an organisation that determines whether they are reacting or in the process of destruction.

Systems theory applies to pattern theory in that patterns are self-constructing systems. I was surprised by how close Christopher Alexander’s theories grew to systems theory over time. Many aspects of The Nature of Order centre around the way systems interact.

In his last book, The Battle for the Life and Beauty of the Earth[Battle12], Christopher Alexander declares two ways of constructing: system A and system B. It’s unclear whether he was referring to systems theory when analysing the fighting between the systems, but his records align with the expectations of a systems theory approach to understanding why things panned out the way they did.

We will start with a primer on systems theory concepts and then move on to learn how recognising policy resistance can help us. Once primed with this knowledge, we can move to new heuristics for recognising whether code is good and find a new definition of good that might upset some people. But at least we can now be on the lookout for bad code to love instead.

Then, we finish the chapter by reviewing other forms of feedback affecting the design pattern movement, anti-patterns, and other pattern forms. Armed with this new lens of systems theory, we can better understand the later chapters and specifically, approach a new understanding of why patterns failed the way they did and what we can do about it.

Senses of systems

Systems react to input all the time. It’s what makes them systems. A pendulum swings under the input of pressure. A seed germinates when the moisture level and temperature are just right. A developer screams when they discover the delivery date has been brought forward by a few weeks.

Systems react because they have senses. Not always literal senses in the form of sight or hearing with eyes or ears but senses nonetheless. When systems react, we must assume they are responding to something that they became conscious of. Reactions are proof that a system has sensed an event. A pendulum does not have a sense of pain, but if we hit it, it does react. This is what we mean by senses. They aren’t senses in a literal interpretation but the ability to respond to a stimulus.

A counterexample might help. A pendulum does not have a sense of temperature. It is not affected by it. The seed senses temperature and reacts. A pendulum does not work well when inverted, so in effect, it perceives the inversion as its behaviour changes. However, the orientation of a seed has minimal impact on it. And, whether you raise their temperature or invert them, a software developer will react to the event and can even tell the difference between the two.

This is what we are talking about here. Senses of systems: not so much a conscious awareness of the outside world, but the ability to be affected by the environment and phenomena. We also want to examine our awareness of these senses and how we can influence them to improve our situation. But first, we need to think a bit deeper about what a phenomenon is.

Phenomena

A team working on a project is a system. We can map the inputs and outputs to responses and behaviours. One such behaviour is the reaction to news about the project’s status. Even though the team is made of humans, they cannot see all the aspects of the project without taking advantage of the right tools to view it. The news about the status is input, that is, phenomena the team can react to.

If you think about our customs for observing progress, you will realise none of the indicators are visible from the outside. The metrics all require you to collect and collate data before estimating. And that’s when you’re working on a project where you deliver early and often. The visibility of progress on large projects with up-front design is low. Progress isn’t a series of phenomena; even if it were, you’d still only know how many there were once you were done. It’s foolish to assume you can come to a reasonable conclusion about the genuine progress made towards a distant goal. In 2021, I believed I would finish writing this book in 2022.

Estimating or calculating the amount of effort put in is easy. You can easily count how many people are currently working. You can calculate hours spent on a project. You can see how many tickets are closed. The measure of effort is evidence-based. You can measure it in cash spent on remuneration if you wish. Even if some people are slow and others fast, the overall effort is measurable.

But progress is only loosely related to effort. Therefore, using effort as an indicator means we don’t have the correct feedback to learn how to progress more effectively while we’re in the middle of the work. We need the right tools to be aware of invisible project attributes such as progress, but we also need tools and lenses through which we will look to gather other information relevant to our work. These tools should provide us with phenomena to which we can react.

A lack of phenomena can be considered a form of blindness. Using ‘can we ship it?’ as our metric creates an easy-to-use measure for progress. It’s a very rough one, but it’s still something. We’re no longer blind. When you estimate you are ninety per cent of the way through a project but don’t believe there is a product hiding in what you have produced so far, it makes for an anxious sense of urgency. That urgency is only present if there are phenomena to sense.

Consider also the types of problems you might like to have, such as too many users to support. Your network goes down because you are at a thousand per cent capacity; more people are using your service than you expected. When you fail to track these things, they can become problems you wish you didn’t have. Why didn’t you react to the situation before it became a problem? It’s probably due to the lack of a phenomenon. If your servers running payment processing go down due to a deluge of people trying to buy from you, it’s a good sign but a bad state to be in. You’ve got a lot of phenomena to work with, but it’s too late to rake in the cash.

Then there’s the blindness to slow changes—the frog in a boiler syndrome. You can’t react to something that changes so slowly that you don’t notice when things get far out of hand. This blindness is sometimes referred to as a shifting baseline. The idea is that local recent deviations are so minor as to cause no ripples or resistance. Then, those measurements become the new baseline against which you compare future data. Slowly, the baseline moves into the zone that would previously have triggered a response. It’s the reason why we sometimes leave it too late when it comes to earthquake and volcano warning systems. The phenomena indicating the future explosion hide in plain sight by moving so slowly that they do not trigger any senses.

When you monitor the right things, you can predict any of these situations before they happen. But when you don’t expect something, you don’t watch for it, so you cannot know about it. By default, all the things we think are impossible are invisible to us and, in turn, we do not worry about them. So, even though we don’t want to be blind, sometimes we don’t even know what we can’t see.

Perspective

What is possible to see is limited by our perspective and our discernment abilities. Our perspective is what we care about and our position. Our power of discernment is what we are attuned to pick up on among the soup of noisy inputs around us. This is the limit of what we can observe. Specialists will usually acquire deep powers of discernment in a specific field, some of which they will not even recognise having. But they can sometimes be utterly blind to systemic phenomena due to their perspective from inside the context of their speciality.

Let’s start by describing perspective with some examples based on views from different domains. There are many examples of words that mean something different even though they sound and are spelt the same way, such as read, arm, band, current, lie, dice, the list goes on and on, and that’s just the ones I can think of quickly. We’re not talking about homonyms here, but rather things that are the same but are seen differently from a different perspective. Those who know about Domain-Driven Design may think of these as Bounded Context.

• Book:
  • A librarian may see Dewey Decimal.
  • A borrower sees a copy of a title.
  • A publisher sees a stock and profit SKU.
• Newspaper:
  • The reader sees journalists/bias or a physical copy.
  • The newsagent sees shelf space, cost, schedule and popularity.
• Bus:
  • The maintenance team sees the vehicle.
  • A potential passenger sees a number or a route.
• Plane:
  • The passenger will get on a flight to a destination.
  • The pilots fly a plane on a route.
  • The airline sees an asset with costs and benefits.

It is only because we all have noses, ears, and eyes that we can say that any one person’s nose, ears, or eyes are distinctive. Tattoos are rarely distinctive because, in cultures and societies where they are rare, the presence of a tattoo is distinctive in itself, relegating the detail of the tattoo to second place. In societies where tattoos are not uncommon, each tattoo will be relatively unique. And if they are all unique, then none are. Distinct tattoos only exist where tattoos are common, but they have a typicality, such as size, placement, colour or design; hence, I tend to notice facial or full-body tattoos, but not others.

We are adapted to recognising slight variations from a well-known hierarchy of features rather than the features themselves. Ask someone to draw someone’s face, and they pick out the variations better than the invariants. They pick out prominent features or scars better than the basic ratios. This is why artists have to study forms and physiology. Without explicit study, accurately drawing natural features is more demanding. Only when an artist has those core features down can they introduce the variations to achieve what we consider to be likenesses or caricatures.

Systems only see the signal. They ignore the expected. They have no need for it; it is not information. This is why artists strive to learn how to make things look natural. They need everything their art is not meant to be about to vanish. They need to be accurate because otherwise, the wrong things become that which is seen.

Responses

It’s always true that reactions happen because something was sensed. Without the initiating sensory stimulation, there cannot be a reaction. Perhaps you think that’s false because you’re wondering about when we detect nothing happening. Well, consider this: When do we notice a lack of activity? Is it arbitrary, or do we have an expectation of when something should have happened? We have a tolerance threshold, and we’re triggered to react when we reach it. A mechanical or biological timer ran its course and became a phenomenon of its own, like a screensaver.

In systems theory, we often talk about stocks and flows. These are the analogue equivalent of the phenomena we mentioned in senses. They aren’t always acted upon directly, but sometimes they are. For example, let’s consider a mundane system. A cistern allows the flow of liquid until it is at capacity. It has a water level, which is a stock, and a soft trigger to allow fluid to gush from the inlet, which is the flow.

A cistern maintains a stock of fluid by reacting to the current level. It’s an elementary feedback loop. The phenomena are analogue, not digital like those we considered before. The reaction is also analogue in many cisterns. The response does not need to be linear, but must be a function of an input. Reactions can be measured and proportional, like how many months you get for embezzling company funds.

Another analogue stock we encounter in software development is deployment pipeline times. As they grow, we reflect an analogue level of annoyance at them. At some point, they trigger a flow of cash to buy new hardware or developer time to fix the build process to make it less intrusive. In some systems, the level at which the cost is acceptable is set low. These are better environments for developers to work, as build times never get out of hand. In organisations where fixing the build time is never addressed, there is an effect on a different analogue flow—one measured on the scale of employee retention rate.

The stocks of any system are wide and varied. In a development organisation, you have staff with varying skill levels, varying productivity, and varying levels of awareness of the organisation’s culture. You have capital in the software and hardware you buy and use. You have a back catalogue of products you can continue to sell without incurring further costs. You have goodwill with other companies, academia, the public, developers outside, and developers inside. You also have money.

The flows of any system are just as varied. You train a certain number of people for a given number of hours per month or year. You hire at a rate and fire or lose employees at a rate. You even promote at a rate. You ship a certain number of features or products per cycle and are sued a number of times a year. You rent, pay wages, bribe officials, and pay the electricity bill. All these flows affect multiple stocks at once. Some are important, others less so.

Reactions will affect stocks, and stocks will affect or trigger reactions. This is the core of what systems are and do. The stocks and flows wrap around and stimulate themselves to act again and again in a loop. What’s unexpected is the types of behaviour they exhibit when chained together in complex ways.

Feedback

The combination of senses and responses is the basis for the core aspect of systems theory. Feedback emerges from these connections and is worth studying as an element in its own right. Feedback makes a system handle input and adjust rather than do what it’s told. It might be easier to explain this with a counterexample. When you plug the bath and run the tap, you are filling the liquid stock. There is no feedback, so the bath will fill at a constant rate until it overflows. If you turn off the tap and remove the plug, the bath will empty. If you want to reduce the water level to a particular height, you must monitor it and stop its flow once the specified height is achieved. Again, this bath example is not a system because it does not act in response to anything (well, perhaps except for the overflowing). It has to be manipulated directly.

The cistern example is a system that maintains a liquid level. This system reacts to the water level dropping, and increases flow. We know it senses because we can detect it responding to input. There is a negative feedback loop. As the gap between the current liquid level and the desired level increases, the flow increases proportionally to reverse the situation. In a steam engine, a governor releases steam to lower the pressure and stop the machine from running too fast. A kettle boils until the bimetallic strip bends enough to switch off the power to the heating element.

Most of these systems are systems of equilibrium. We call these negative feedback systems, as they are self-righting. Their design pushes back against increasing or decreasing stock by altering one or more flows to return it to an equilibrium point. Systems can have positive feedback loops, but these are generally unstable and unsustainable. For example, over-fishing reduces fish stocks, which leads to fewer new fish, which means any fishing is now over-fishing. The high-pitched sound of a microphone too close to its speaker is caused by the amplifier amplifying the sound it just played over a loudspeaker. The amount of ice on Earth affects the ability to reflect the sun’s rays; as it melts, the amount of heat captured by the land and oceans increases, increasing the average temperature of the planet and reducing the amount of ice on Earth. Positive feedback loops tend to cause runaway behaviour where the response needs to be quickly halted before it becomes uncontrollable.

So much of our lives is driven by the concept of feedback. Evolution is a feedback mechanism, and so is Scrum. Systems theory is all about feedback and the manner in which things react to each other. Christopher Alexander’s work crashed into feedback loops multiple times. At the core of all living processes lie mechanisms to create phenomena, sense them, and adjust future behaviour in response.

What does developer feedback look like? How about promotions, raises, bonuses, and other forms of reward? They are feedback, so how does a developer respond? Well, only rarely in the way the person inventing the reward mechanism intended. As mentioned before, a complex system responds as designed, not as intended. It follows the path of least resistance, fulfilling the wish as deviously as possible to gain the reward without expending any unnecessary effort.

When you praise or promote programmers for creating new features and rolling them out, you create a culture of making new things and ignoring maintenance issues. Old features are dropped in favour of bonus- or promotion-worthy work. If, instead, you reward programmers for fixing bugs, they spend less time protecting the code against future bugs and more time developing it in a way that bugs are minor but noticeable and easy to repair. Feedback is a powerful tool but it can create strange situations you don’t want.

What about code? Code has feedback too. When code is difficult to write and debug, it becomes hardened to change. Feedback from the code informs the developer it’s unsafe to make changes. Therefore, it stays unchanged. This makes it even less safe to change, reinforcing stasis until replacing it wholesale, cutting it out like an unwanted growth. Code that is frequently changed due to many small bugs gets changed a lot in the future. People will suspect it is the cause of new bugs. Without good tests, any change for the better will likely introduce new bugs, as the code was previously proven to be ripe for side effects. It becomes a self-fulfilling prophecy, which is a form of positive feedback loop.

Motivation

Complete builds take longer, so integration takes longer, so people only attempt a final build once a week. This positive feedback loop can snowball as the reaction to long builds makes them longer. A weekly build means there is more to integrate, so that begins to take more than a day, so you make it fortnightly. Now there’s more to integrate, so builds take a few days to prepare, so you make it monthly, and on it goes until you have annual releases.

Client feedback on a project, if it’s overly negative or personal, will not be taken gracefully. This leads to wanting feedback less often, so you wait for longer between feedback meetings. The longer the gap between sessions, the more you invest before determining whether you took the right direction. The more changes they review, the higher the probability of a mistake of judgement or interpretation of your client’s needs. This will displease them, leading to worse discussions—another negativity-based positive feedback loop.

Positive feedback loops need not always be about bad things. When you pick up a new tool or library, your work improves. This makes you feel good about picking up new tools, so you do it more. The loop is positive and beneficial.

Systems theory gives us tools for how to think about motivating people. Motivation by reward is a form of feedback loop. You are motivated by the reward to do a thing; your response is to do the thing. If I want you to do a thing, how do I reward you so that you do what I want you to do? Rewards and punishment work well for some limited situations. However, research into what drives people to do great work has proven this type of motivation to be complicated and fraught with dangerous consequences if done wrong.

Paying people to work only succeeds to a certain extent, and trying to get more out of people by promising bonuses and extra rewards beyond what they need tends to backfire. Frederick Herzberg’s two-factor theory of workplace satisfaction suggests that money and other extrinsic motivators only work as negative motivators: if it’s missing, it acts as a disincentive. It doesn’t act as an incentive to work, but a lack of it is a reason to down tools. Money is a requirement, not a bonus.

The other problem with extrinsic motivators is how they generally don’t get people to act honestly. When you reward people with money for doing something, and they want the money, they can tend towards meeting the letter of the agreement over the intent of the deal—just as we saw with building contractors using the cheapest materials within design tolerance.

Perverse incentives

If you want to get something done, you’re better off explaining the value in the result and leaving people to solve the problem for themselves. Telling people what to do to solve your problem and rewarding them for doing what you tell them turns them into robots, and they act with as much emotional commitment. Consider the case of perverse incentives, sometimes called the Cobra effect.

There is a famous myth¹ where the British Raj in India was not pleased with the number of cobras around, so they decided to cull their numbers. The British, being the British, made two mistakes typical of their heritage. The first was to underestimate the capacity of thought of anyone not from Britain.

Rather than do the culling themselves, the Raj decided to outsource the problem. Instead of asking the local population to decrease the snake population using their initiative and rewarding them appropriately, they offered a cash incentive for bringing dead cobras to the Raj. The idea was to reduce the number of cobras by buying them until none were left.

However, people are smart. When told they could get paid for bringing cobras to the Raj, the locals decided upon the wonderfully counterproductive plan of breeding cobras specifically for selling to the Raj. And so, the natural cobra population stabilised. In addition, the Raj paid more each day with no visible impact. This went on for some time until either someone noticed what was happening or the Raj thought the approach wasn’t working, so they gave up and stopped paying for the cobras.

But that wasn’t the worst of it. The second mistake the British made was believing their decisions had no lasting impact. When they reversed their rules, they assumed things would go back to the way they were before. But the environment had changed. There were now quite a few cobra farms. When the Raj stopped buying cobras, the farms had no reason to keep operating, so they closed down. Rather than wasting time killing the cobras, the farmers stopped working the snake farms and set the cobras free. In effect, the Raj had accidentally paid to increase the population of cobras in the region.

The veracity of the story notwithstanding, the problem with reward mechanisms of this kind is that they do not consider how systems reconfigure themselves to take advantage of any newly introduced responses to stocks and flows.

Misaligned goals

Another problem can be when you try to improve things but forget your core goal. The Raj didn’t want cobras. Rewarding their presence in any location wasn’t aligned with their goal. When you want to remove something, look for ways to reinforce removal, not movement or arrival in another location. When you want to gain something, look for ways to reinforce increase, not borrowing, stealing, or having more than another, as this last example often leads to destruction.

An example in living memory for many programmers will be the Hacktoberfest T-shirt debacle. People were to be rewarded for making pull requests, not for improving the repositories. The co-ordinators of the event did not foresee the impact. Updates to README.md files and actively dangerous changes were suggested, all in the name of gaining a branded item of clothing. The sudden influx of low-quality pull-requests imposed additional work on many open-source projects’ maintainers.

If you reward programmers based on the number of lines of code they write, they will produce a lot of lines of code. Suppose you reward testers on the number of bugs they find. In that case, they will generate multiple bugs for the same issue and prioritise the types of work where entering new bugs happens more frequently over finding more difficult-to-notice bugs or regressing existing bugs. Just like the police, who have an arrest quota, might decide to patrol neighbourhoods known for higher crime levels so that they have a better chance of making their numbers. You don’t want testers to behave like the police of your application.

If you reward your programmers for fixing bugs, you might even notice them creating bugs so they can resolve them or closing bugs as fixed when they weren’t sure because fixing ten bugs at a 50% chance of success is better than solving three for sure as far as rewards go. That’s without entertaining the problem of programmer overconfidence in their debugging and fixing skills.

Align incentives

In summary, feedback is a powerful tool you must always keep in mind when looking to write policies or tactics for your strategies. A poorly conceived policy can backfire, and a misaligned tactic can worsen things in the long run.

• Look to the core goal of your strategy and make sure that your incentives align with it.
• Give the job of solving the problem to the people at the place where it can be resolved.
• Make your goal transparent, and let others know why you desire it and what problem it solves.
• Give others the ability to see the quality they bring by solving your problem well.

These actions allow autonomy and open the path to a sense of achievement and mastery of the problem. So, incentivise solving your problem, not exploiting the wording of your command. There are many ways to reward people for achieving your goal that require almost no investment on your part. For example, many people don’t want to merely solve a problem; they also want to tell others how awesome they are at doing it.

When we think of patterns, we must not think of them as raw materials or thought-free processes. They are never modules we slap onto an existing system. They are organisations of relationships between things, between the raw materials at worst.

It’s normal for something not to be its raw materials. We can identify things as their configuration. They can be the pattern of how they move or their path of growth or reactions. A whirlpool is not just water; it is the form and energy of it. Otherwise, you could capture it in a bucket and take it somewhere else.

for i = last; i > first; --i:  # 1: loop over everything
   for j = 1; j < i; ++j:       # and loop inside that loop
      if val[j - 1] > val[j]:    # 2: check if we are ordered
         temp = val[j]            # 3: cache a value
         val[j] = val[j - 1]      # and copy a value
         val[j-1] = temp          # and overwrite with the cache

These parts of the algorithm are the Structure in section 1, the Sensor in section 2, and the Reaction in section 3. It can sort two elements using only the Sensor and Reaction. For more, we must introduce Structure. But notice it can only do something when it has a Sensor. If it acts without observing, it is not a system. As soon as you have a structure with an observation and a resultant action, it is a system.

Patterns are forests in this way because they explain how a living collection works together to create, maintain, and heal. There’s less healing in programming, but repair is still important and shows why patterns and agile, iterative approaches are related. The observer in patterns is the programmer, observing the interplay between the code as it is and the unfulfilled requirements. The programmer reviews, decides, and acts. The pattern defines the observations you must complete to determine which of its steps to take and where.

Code that survives is good at surviving

Good code survives because it creates an environment in which programmers survive. The environment is important. Software development is an ecosystem. This is because programmers inhabit codebases, but there are other competing inhabitants too. The things that survive in an environment are the replicating entities or the entities that spread and grow and their hosts. Whatever meets these criteria, whether biological or memetic, counts as an inhabitant in the environment.

Code

Code survives, or at least configurations of code do. Sequences of code can be copied, altered, deleted, or stay. These sequences and relations are the thing that is replicated with an opportunity to change. Thus, we can call them memes in the original sense. Some of the structure survives the copying process, and we give names to that which survives to enable discussion. When we name a thing, its chances of survival go up because it becomes a bounded concept. We document protocols, not sets of ten lines of operations. We write comments for functions and procedures, not every 100 bytes of machine code. We capture the recognisable patterns and how the sequences interact to bring about a change. These named features will be carried through the copying and mutation steps.

Conversely, it’s not a great idea to assume code that survives is good for developers and clients. After all, anti-patterns exist. The attributes allowing code to survive don’t match what we normally call good or valuable code. Unfortunately for us, code that survives doesn’t equate to high-performance code. Just because code is static doesn’t mean it’s correct or even provides users with value. No, indeed, code that survives has attributes perfectly tuned to make the code survive. That is all. It’s good, but not good for us.

Beyond surviving, some code gathers momentum and picks up programmers or codebases in which to survive. Where other code stays put and lingers in only one codebase, some code drags in other libraries or ways of thinking and becomes even more robust. They bring an environment with them. They infect minds with their values. This ability to spread to new hosts makes a piece of code viral. It’s different again from a pattern in that it’s not necessarily a self-forming system or structure of relationships. But when it does spontaneously form, it maintains its idioms very strongly.

There are a few recognisable attributes that make code inviting to a host. Here are a few that stand out.

• Solves your problem:
  • It’s easy to see the value of the code—what problems it solves.
  • You can tell it will solve a real problem you are having right now.
• Unambiguous:
  • Is is easy to understand what the code intends to do.
  • Examples show how it works with glue code.
  • It is something you can touch; you can see the source.
• Highly rated:
  • There is a community of positive comments.
  • Products made with it show good results.
  • ‘Not getting fired for buying IBM.’
• Safe:
  • There are no known issues with the library.
  • The community has no major outstanding concerns or caveats.
  • The license is compatible with your use case.
• Slot-in replacement:
  • It is easy to add to an existing codebase.
  • It could even be part of the language in the near future.
  • It could be as simple as copy-pasting¹ it in.
• Gentle start:
  • It has easy-to-read documentation or is designed so that documentation is unnecessary.
  • The API is quick to get started with, and defaults are sensible.

I am torn to mention other things experienced developers care about, and remember, not everyone considers these. Even though they make a library valuable to someone with experience, lacking these won’t immediately make it less likely to go viral. The inexperienced outnumber the experienced. It’s a quality of the environment, and therefore part of the situation we find ourselves in.

• Deep on inspection:
  • A small API with extra depth and options hidden under the surface shows care about someone needing to refine their use later in development.
  • A shallow API with everything completely hidden will become a burden later on in a project, so it will repel experienced programmers.
• Clear error messages: or good logging features.
  • Anything that shows the library developer knows terrible things happen and understands people are going to want to figure out what they were and why.
  • Scripting languages that are perfect in every way but don’t have debug output or breakpointing built-in become dangerous time-sinks.
• Awareness or compatibility with more platforms:
  • It’s not only that the code will be compatible when there is a shift to a different platform but also that a multi-platform library is less likely to have structural issues limiting its usage to single development environments.
• Lots of examples of usage:
  • Documentation is one thing, but a suite of tests and examples
    • shows you how things are done, and
    • proves things are working.

Vestigial organs

Much like our appendix or tailbone, codebases can carry code that no longer serves a purpose. As long as it isn’t hurting anyone and remains out of sight, it can quietly take up compilation time and hard drive space without being disturbed. We carry around code that doesn’t work for several reasons. Sometimes, it’s physical, such as when the code inhabits the same files or folders as other code we actively use. Sometimes, it’s historic code for which there is little reason to inspect how or whether it works. Any old code we didn’t delete when it ceased being necessary will remain for months or years.

Getting rid of unused code can be difficult. If you don’t include unit tests, it is possible to use code coverage tools to see what is used in your codebase. You might use higher-level tests, such as integration or end-to-end tests, to deduce what code isn’t really required. But most developers don’t think to do this kind of proactive work to discover unnecessary code. In some cases, it’s impossible because your project might be a library for others, and you cannot run their code to review usage.

There are cases of faulty code being carried along as safe and trustworthy. When a library has proven, through positive evidence to be valuable and safe, vestigial faulty code can hide in less-travelled places. An otherwise safe library can be rendered a security risk when a route through the code previously untested becomes a new hot spot. High code coverage can help here, but nothing will protect you against incorrectly written tests or tests proving the code matches an incorrect design.

We take code with us from place to place for many reasons, but the two that crop up the most are these.

• Old code is comfortable. A worse but familiar API is better than a new one for those not fed up with it.
• Cleaning up before bringing it over is work. This means untested but existing code is preferable to new or unknown code with many tests.

You can see the danger in this. We trust the old code we have dragged from project to project, but when we finally start to use it, we find bugs and missing features. Individual bugs don’t feel like a significant cost. But together, an old codebase can contain hundreds or thousands of traps for an unwary developer.

Paradigms and mental models

Paradigms leak into how programmers think about the codebase and spread without impediment. When code pushes against an entrenched paradigm, it can be rejected during code review as not aligned. Familiarity is very comforting to many programmers. Unfamiliar code doesn’t have to be wrong for us to reject it. It’s a clash where we equate foreign-to-our-thinking with being technically wrong.

We should define wrong code as producing incorrect behaviour for given inputs. But when a reviewer claims code is only correct if it follows style and paradigm, then our code isn’t correct, even if it would add value to the customer. So, we must understand the environmental aspect again. Correct code, as in functionally correct, is only correct regarding the spec, even with comments explaining the reason why the change was made. Code exists in the environment but also creates one in which programmers will make further changes.

If the new, technically better, unaligned code makes it into the codebase, it creates tension. Someone may come along and clean it up back to the original paradigm, possibly breaking it, even if it was objectively better left untouched. I have seen some programmers reverting valuable optimisations because they did not see the value in the change or preferred the paradigm-aligned code over fast or flexible code. The spec is important, but you must also be aware of the environment in which the code resides.

Idioms and processes

Traditions spread too. This is less about a paradigm than about a habit or a technique. Idioms can stick around beyond their value until they become detrimental, and then it can take a while for people to break the habit of reintroducing them.

Getting C programmers to program C++ idiomatically takes a lot of work. Helping them migrate away from raw pointers for objects and moving to shared pointers and value types has been difficult. Trying to get modern C++ programmers to stop using for loops and prefer using algorithms for performance and correctness has been difficult due to the infectious nature of raw loops in code.

Politics

If some code was hard to write, we naturally feel it has value. The feeling can be pretty strong. Deletion of defective code becomes politically tricky. No matter how well your source control works, some people don’t want to see working code removed from the main codebase. This is an anti-pattern because unused code has no value, and any code in a codebase limits what code you can add and how you can change the code. Delete the dead code.

Complex code also hangs around longer because people fear the sunk cost. Even if the complicated code isn’t used, the fear of writing it again is too intense for some to bear. People fear the cost of rewriting complicated code but for some reason don’t fear maintenance or knock-on costs as much as they should. Bad code exploits this as a survival trait. The more difficult it looks to write, the more likely it will get to stay around. Not only that, but it breeds too. A programmer surrounded by complicated-looking code is inclined to add more complicated code. The opposite may also be true. In line with the broken windows theory, simple, clean, good code reinforces good practices by its presence, but any dirty code lowers the bar for what is acceptable.

The most complicated, unused, slightly wrong, poorly performing, untested code can hang around for a long time if it was difficult to develop, especially if the original author is still part of the organisation and even more so if they are now a senior staff member. It’s not uncommon to find architects inventing or at least naturally including a pet project they worked on when they were a senior developer. That which is familiar is simple to them. Trying to prise an implementation detail away from an architect can be a dangerous political game. So long as the code strokes the ego of the most senior staff members, it will survive.

System of ego

For many years, Christopher Alexander worked directly on building sites while also continuing to work as an architect. He learned the engineering skills and builder’s yard talents necessary to create with his own hands. He knew the materials better through this immersion. He worked with others to construct many buildings and worked with organisations large and small. He knew the interactions of those in the trade better through this process.

Alexander shared his knowledge as he formed the written works The Timeless Way of Building[TTWoB79], A Pattern Language[APL77], and The Oregon Experiment[TOE75]. These tomes weren’t produced from some ivory tower but from the mind of someone proving their theories in the field. A little later, he worked on The Linz Café[DLC82], a project for a single commercial building, and then did the same with a housing project, publishing The Production of Houses[TPoH85]. All these projects increasingly tie together his ideas into a web of techniques, finally bringing something genuinely new to architecture.

Initially and in parallel, the architectural establishment praised him from their vantage. His new work created an opportunity for revolutionary techniques in planning buildings of many scales. His work on A Pattern Language was used directly in the planning and construction of many areas of the University of Oregon. And he founded the Center for Environmental Structure, to which most of his activities were linked.

The problems he saw in architecture reflected back on him as those invested in the status quo found him difficult to accept into their world. His theories began to break down barriers previously held to be impenetrable. Architecture had, before this point, been viewed as an art¹. It required many years of study to become an architect who could put together a building expressing the values of its commissioner while maintaining the physical constraints of construction.

While the idea of creating a pattern language was novel and exciting to the architects of the time, the problems started when those from the establishment realised he had made something that was not built to support artistic visions².

This is not to say Christopher Alexander’s buildings were purely functional—quite the contrary. However, anything produced using his methods would be something that used art to complete the form and bring harmony. Artwork and iconography were materials used, like wood and steel, to make a building more fully what it should be.

What is often called the “detail” of the building — its fine structure — is not some kind of icing on the cake, but its fine structure, the essence of what it is, and how it makes its impact upon us. The detailed pattern and ornament of which a building is made, is as much the essence of its structure, as the arrangement of sodium and chlorine atoms, is the essence of salt; or as the detailed arrangement of the amino acids is the essence of a human chromosome.

— Christopher Alexander, A Foreshadowing of 21^st Century Art[AFo21CA93], pp. 7–8.

Christopher Alexander did not think of ornamentation as something you add to a building but as a valuable, perhaps essential part of it. In effect, you might say his buildings used art, whereas for modern architects, their art used buildings.

The following three images are kindly provided by the Centre for Environmental Structure. Though they are all Christopher Alexander’s work, they are each different in detail because they use art and style to deeply resonate with their purpose. None of the art is for the sake of some statement, but instead to help complete the building.

— Christopher Alexander, The Center for Environmental Structure, The Nature of Order, Book 2[NoO2-02], p. 405.

The West Dean Visitor Centre (above) is a beautiful building constructed from both traditional and modern materials. The combination of bricks and flint is a style in keeping with local buildings and provides a sense of continuity. The overall design is unique to the project but seems emergent from the environment rather than an attempt to announce itself by contrast.

— Christopher Alexander, The Center for Environmental Structure, The Nature of Order, Book 2[NoO2-02], p. 429.

The wooden forms of the Eishin Campus include many works of beauty while also providing essential structural integrity.

— Christopher Alexander, The Center for Environmental Structure, The Nature of Order, Book 2[NoO2-02], p. 457.

Projects for families and individuals, such as the above, were developed to suit the needs of the homeowners and the land around them. Beauty was seen as a requirement during development, not something tacked on after.

Democratised development

A Pattern Language was accessible. People could use it to build the places they lived, loved, and worked in. It wasn’t for monuments or edifices dedicated to a concept or king but for places where memories could be made and communities could grow. It was intended for a manual labourer to read and understand the necessary steps to build according to their needs. With it, they could build their homes with only the occasional correction. This threatened the establishment. It empowered laypeople to solve their architectural problems without resorting to prefabricated construction. It also threatened governments by suggesting people build their work environment around how they worked best and not according to easy-to-verify modular designs.

This alone would have been enough, but it also appeared to give nothing to those who wanted to build to express themselves or create a physical manifestation of a statement. In the light of modern architecture, this was absurd and dangerous. The architectural establishment fought back by claiming Christopher Alexander was ‘anti-intellectual, naive, soft-headed, conservative, and uninterested in architecture as art’³. But beyond that, the threat went deeper. His work attacked their very values. It silently insinuated that the idea of an architect wanting to leave a mark and make an impression was itself, a foul goal. He was a massive proponent of an ego-free approach to construction⁴, believing ego was at the root of many of the most discordant buildings[NoO2-02][NoO3-05].

Architects had been brought up to believe their trade was all about making an impression, expressing something meaningful with the materials they had. Architecture was an engineering science, but the basis was artistic intent. When Christopher Alexander came along and claimed architecture was a job you should do to satisfy human needs, he implied their whole career was a sham—or conceivably worse, a destructive, wasteful distraction in the world.

Across architectural literature on Alexander, there was a tendency to talk about him in the past tense, as a curiosity, not a futurist. They would occasionally downplay his paradigm-shifting views as dreamy references to a time long gone and of no particular value in the modern world[NoO4-04]. In 1982, this bizarre reaction was used to create a bit of a performance in a staged debate[Debate82] at Harvard University between Christopher Alexander and Peter Eisenman.

At one point late in the debate, Christopher Alexander became angry at the idea of actually seeking out disharmony in architecture. He said:

Moneo intentionally wants to produce an effect of disharmony. Maybe even of incongruity. … I find that incomprehensible. I find it very irresponsible. I find it nutty. I feel sorry for the man. I also feel incredibly angry because he is fucking up the world.

— Christopher Alexander

For this, he is applauded, but the modern architect Peter Eisenman later said:

How does someone become so powerful if he is screwing up the world? I mean somebody is going to see through that …

— Peter Eisenman

This then led to further arguments before the debate came to an end.

For me, Eisenman’s belief that there would be consequences for making mistakes or causing problems was probably the root of many issues impeding Christopher Alexander. I suggest Eisenman’s belief in some inherent corrective justice was a quaint Victorian notion, to pre-use a phrase we shall encounter later.

I’m afraid I have to disagree with Eisenman on this point. I’m a child of the 90s, so I have seen plenty of evidence in my lifetime that people doing the wrong thing do not get pulled up for it if they work within the letter of the law. As a child, television taught me that bad people were punished, but in real life, I was taught people could get paid a lot more money if they did the wrong thing. What is at play here is a system that doesn’t just tolerate someone screwing up the world, but either doesn’t see it⁵ or possibly applauds it for testing the boundaries of artistic expression. The most salient point here is that mistakes are subjective. Something is sensing them and reacting—a system.

If you cause problems, you will only be noticed and blamed if they’re the kinds of problems that are obviously problems and you’re obviously wrong. There’s also the filter of these problems having to be problems for the people in power. There are many things people can do or ask people to do that can slow things down or increase waste, while on the surface, appearing to be very normal and acceptable or even the obviously correct action. In the case of Peter Eisenman and Moneo, they both have an institution-sized self-congratulating in-group supporting their egocentric approach to architecture. That’s a lot of people in power not seeing anything they would consider a problem paying these modern architects tribute for the damage they did.

However, we’re not institutionalised architects; we can think for ourselves and see through the faux intellectual arguments for the balance of harmony and disharmony. We can point out that balance is harmony, so introducing discord and disharmony to balance with harmony is like showing both sides of the climate debate. It’s disingenuous at best. It’s sneaky rhetoric with no real value other than maintaining the status quo—a world in which those who do damage are rewarded, not reprimanded.

I believe harmony is about striving for a form of invisibility. Ego is the opposite; thus ego is not harmonious.

Christopher Alexander was fighting a system that had emerged from traditional architecture but was no longer playing by the same rules. The new goals were no longer aligned with the people who used and inhabited the buildings. Instead, it worked for those who put up the capital to build them and those who needed the commissions. The system rejected the pattern language approach because that approach denied the architect their fame and provided no opportunity for the client to flaunt their wealth.

This system and its response are mirrored in many structures of authority. The software pattern movement suffered a similar fate. I’m convinced that each year, at least one organisation suffers the same rejection of progress. You need to understand systems theory to fight against such processes. In this case, ego and authority used qualification and accreditation to protect those who would have suffered most under a revolution in architectural thinking.

Extrinsic and intrinsic effectiveness

We need to understand the difference between intrinsic effectiveness and extrinsic effectiveness. These are the terms I use. I believe they unambiguously capture a noteworthy attribute of systems. Intrinsic pertains to things internal and essential, and extrinsic applies to those attributes from without. Effectiveness in the sense of systems is their value, and anything’s value to itself will be related to its continuation—its autopoietic strength.

Most people think about extrinsic effectiveness when it comes to their code or engineering projects. It’s your typical performance measurement. It’s your acceptance criteria or your metric for success. In effect, extrinsic effectiveness is how well the system performs when measured against your selected goals, the measurements someone above you in a hierarchy would be concerned with, or the ones the market responds to. It’s often the part you want to maximise or adjust to reap the amplest bounty.

Elements can straddle the gap between these domains. Anything that does well according to its extrinsic metric will likely be repeated, continuing the system based on extrinsic values. In effect, introspective systems turn the extrinsic effectiveness of their components into intrinsic effectiveness by being an environment that selects for those attributes.

Opposing forces

The intrinsic effectiveness domain relates to the performance of any system in regard to maintaining its existence, that is, the system’s inherent survival traits. It’s not the same as extrinsic effectiveness and can often be opposing. Consider the power of poorly managed agile development. The system of badly implemented Agile principles is powerful because, like governmental systems, anyone inside the system saying it’s not working and it’s hurting more than helping will be told, ‘It’s not X’s fault. You’re not doing X right’. The intrinsic effectiveness of a system can be its immunity to contradiction or removal. You might recognise this as the attributes of a virulent meme.

Remember, each system has two different areas of effectiveness. Systems with intrinsic effectiveness include those of doomed complexity. Such as when an architectural design or pattern appears to be more flexible or cleaner than the straightforward dumb technique, but needs fix after fix after fix for each corner case encountered, thus rendering the clever, clear solution neither clear nor valuable. But it is clever in an evil way, as it is self-maintaining.

Another example is that when patches or workarounds become the norm, people should consider how patches affect normal operation. Current CPU architecture results from our coding techniques over the last few decades. If you honestly want to get the most out of the available materials, you can’t. I mean the literal material, as in silicon, copper, and gold. The architecture we have these days is not an optimal solution. Rather, it’s a solution to a different problem, the problem of running code as it has been written up until now.

Similarly, GPU drivers are the result of the most commonly used graphics techniques. The Vulkan® API came about because the set of capabilities of a GPU had stabilised, and the rate at which new clever optimisation techniques were arriving was slowing down. The new API removed some of the previous limitations.

We will likely see the same pattern play out every decade and a half. New technology will eliminate the complex helper functions that burden the highly efficient architecture developed under the previous generation’s best-performing solutions.

Some people believe this happened with mobile CPUs and will occur with newer architectures, but the CPU domain is strange in that the dominating consumer PC operating system holds it back from taking on new technology. A walled-garden operating system allows for easier migration, and we have seen that happen multiple times with Apple® switching architecture not just once or twice, but three times. The intrinsic effectiveness of the x86 instruction set is the symbiotic relationship with the Microsoft Windows™ operating system’s commitment to backwards compatibility.

Extrinsic and intrinsic effectiveness are orthogonal to each other. You can have one without the other. The problematic systems are those tenacious ones with weak extrinsic effectiveness. And that leads into the next section: patterns that exhibit strong intrinsic effectiveness but have weak or even negative value to their inhabitants.

Anti-patterns

As said before, anti-patterns are self-reinforcing, like all patterns. They are feedback loops, but unlike other patterns, they consume energy from their hosts rather than protect or repair.

We see an anti-pattern in action in the staged debate[Debate82]. Peter Eisenman appeared to believe there were consequences for making mistakes or causing problems. This belief is probably the root of many issues in many organisations. But it’s just that. It’s a belief. It’s not true.

I will repeat again for those who missed it earlier: if you cause problems, you will only be blamed for them if they’re the kinds of problems affecting those in power.

It’s not just in architecture. These cultural anti-patterns are everywhere. Think about the number of times you’ve heard someone suggest,

And no one calls them out on how working closer on a project can decrease speed because communication becomes a massive overhead. Or perhaps they say,

But again, no one fights back, even though the meetings could be lengthy because things still need to be disambiguated, and getting stuff done would be getting the wrong stuff done badly.

Both these statements could be true. However, you could make either statement about the same situation, and neither would be out of place. So which do you choose? When an observation cannot be denied, and the action seems like a reasonable correction, why would you try to stop it? This action-paradox blindness can affect any group that prioritises solutions over analysis.

This also happens when you are surrounded by people who think similarly or when the solution is outside your normal range of strategic comprehension. We reinforce bad solutions to our problems. As another example, if everyone has been educated in business in the same cost-accounting way, you can end up with everyone trying to cut costs rather than raise profits, dooming the company to a slow death.

A system will hand out rewards for actions it considers correct. If it hands out a reward, the action will be repeated or strengthened. If the senses of a system are tuned to reward poisoning the well, the well will be poisoned while people gather around to cheer on the poisoners.

People have such a deep belief in natural justice that they can’t see the anti-patterns. However, you don’t need to recognise or understand the feedback loop to be affected by it. Interestingly, you can ferret out anti-patterns without knowing their specifics, as many use the same defence mechanisms to maintain their presence.

Age as a defence mechanism

Age provides a sense of validity, even when the ancient element or action is detrimental. We spent a long time assuming bloodletting was a good treatment for diseases. I can fully well imagine a town planner saying ‘Zoning must work at least to some degree because it’s lasted so long’, but this assumes age is an indicator of goodness.

Zoning as a way of restricting the types of buildings in an area has been around for a very long time, going back as far as disallowing certain building types within the walls of a medieval walled city. But what we normally mean by zoning, where the government maps out residents and industry and strictly enforces the law, has only been around for a little over a hundred years.

Just because something has been around for a long time doesn’t mean it’s good. It’s hilarious that the people who use this argument for why zoning is good are the same ones who say traditional architecture isn’t good because it’s old. Something must be wrong here. It must be about more than whether or not something has worked for a long time, as that only means it’s remained active after installing itself. That’s the reason why we have to think about the differences between extrinsic and intrinsic effectiveness.

Zoning was an idea that worked to some extent, but we misunderstand what success means if we ignore intrinsic effectiveness. We need to reconsider these stories in light of what keeps them alive. The property that makes anything a living pattern is its tendency to survive. To this end, we should ask if something is fit for its environment. So, we must investigate the environment.

For zoning, the environment is an everyday North American Western democratic policed capitalist environment. It’s an environment where money will tell you what will get made, as breaking the rules has very little value when there are armed guards to deter you. In this case, if you start a practice of zoning, you will end up reinforcing the zoned areas because one zone type generally begets another in response.

An industrial zone begets workforce residential zones, which beget commercial zones. Once you have many of them, external systems cater for them. Road layouts and utilities become zone-typical.

• Concrete pouring contractors pop up next to highways built with concrete so that their concrete can reach greater distances.
• Systems to build become specialised, with timber merchants extending into making regular-sized stud walls, standard height stairs, and predefined apex angles.
• Shops and malls are built with ample parking to cater for the distance to the residential or industrial areas.

Buildings are erected in zones before their need has been established as developers see a pattern of demand, and being early can lead to profit. More garages and car dealerships appear as the demand for public transport will far outgrow the capacity to provide it because funds will be allocated to services with greater voter impact. More cars demand more fuel and infrastructure, so land is claimed fast to keep costs low. The low land cost makes building large low houses cheap, extending the sprawl’s breadth and making car transport ubiquitous.

All these support systems and the reactions to them make it harder to build non-zoned areas. Non-zoned areas are seen as complicated or bespoke. Centralised command and control economies are generally wary of bespoke constructions. They sound expensive and unregulatable.

But it’s not all bad, right?

Zoning builds infrastructure efficiently for a known purpose. It’s good for keeping people’s homes away from pollution. It’s excellent for making deliveries to commercial buildings easy and non-intrusive. Malls that take deliveries through an entrance separate from the public parking area allow for constant deliveries throughout the day without interrupting commerce or the public from using any of the facilities. In an old city such as London, delivery trucks can get in the way of pedestrian traffic and passenger vehicles.

It would seem that zoning does have a positive value. But it’s an anti-pattern because, despite its apparent benefits, it also has worrying drawbacks.

When you move people away from pollution caused by industries, you make it easier for people to forget they exist, reducing the incentive for the industry to comply with regulations. You also move people away from each other during the day, thereby not only extending the time families spend away from each other by commuting but also inhibiting bonding over breaks such as lunch.

You make it harder for neighbourhoods to build up, as many inter-family bonding activities spark from recreation or work. When you travel by automobile to commercial and industrial districts, you lose another link to your neighbours. Making cars, trains, and buses the standard way to get to work and play produces more roads overall.

All this leads to less land to build on for everything else. It also puts more cars on the road, which is energy-inefficient for the country but a natural consequence of failing to build good public transport into your zoning laws.

What happens when you don’t have zoning? You end up with cities that have their own problems, but you don’t end up stuck in a cycle of enforcing non-zoning. London is a large city with little in the way of zoning laws. Building up the city has taken a very long time, but its structure allows walking to work even today. European towns and villages are walkable, with homes often less than a mile from commercial and industrial workplaces. Whether this is better is somewhat subjective, but the health of those living in European countries is, as a matter of record, better than that of the average U.S. citizen.

Now consider pull-requests. They work to some extent. However, the lack of fast feedback leads to increased rework and they invite more work in progress as you start on something else while waiting for a review. As a reviewer, they interrupt flow which also indicates movement between developers. These are all negatives according to Lean methodology. Is the pull-request concept an anti-pattern?

We’ve always done it that way

Except, nothing is ever how we’ve always done it. Someone was the first, and someone will be the last. What’s new is not easy. What is old is easy, even if it’s complex. The talk by Rich Hickey, Simple Made Easy, points out the difference between easy and simple and hard and complex. But the one point that hits home regarding the anti-pattern of We’ve always done it that way is that what’s familiar is easy.

When you’re an old hand on a project, complex things can appear easy because they are familiar, even if they are complex. When you’re new to a project, everything is both how it’s always been done, and yet also strange and unfamiliar.

Therefore, to you, because nothing is familiar, nothing is easy. Some things are both hard and complex. When you point out how complex something is, you can be met with dismissive comments due to how familiar, and therefore easy, the complex design seems to the old hands.

When you arrive fresh at a project, you expect everything currently there to be a rule for how things are done. It’s very difficult to announce,

While you’re still getting your bearings, you want to ensure you understand everything. You ask questions, but they’re usually in the style of how, not why. And that’s normal. People won’t argue against existing stuff easily. They haven’t the confidence. If they’ve just turned up, then everything is solid and known and unchanging to their eyes.

People onboard to a team and notice things that shouldn’t be the way they are. They will wonder why but not say anything. They can’t claim it could be better because they don’t know the level of investment. Maybe it’s only been there for two or three weeks, and someone who doubted their understanding of what they were trying to solve implemented it on a whim. It could have been there for many years and shipped multiple products. Without asking and knowing, it’s difficult to raise an issue. It saps your energy, and you only have a limited amount of willpower. When you’re new to the job, you’re also worried about ruffling feathers, so you tend to be nicer than you probably should be.

We’ve always done it that way is an anti-pattern—a really strong one. It’s reinforced by people coming late to a project who have better ideas but feel they can’t say anything. It reinforces the idea that we should restore rather than repair or improve to achieve something different and better.

We’ve always done it that way is a case of being stuck in a valley of success in a mountain range you can’t get out of because everywhere else looks terrible from where you are. You can’t even see the real problems you’ve been causing.

They fight for themselves, whether good or bad

Positive patterns, not anti-patterns, create negative feedback loops (self-righting) that reinforce good and healthy actions for their environment. They create systems that fight against disruptive forces. They repair damage and self-create when other patterns are present. But much of the same applies to anti-patterns. The only thing that differs is our interpretation of the result of the actions. If the actions are not seen as healthy for the hosts or environment, we call them anti-patterns. Destructive anti-patterns can create self-fulfilling bad behaviour. Just because a pattern is self-reinforcing doesn’t make it good or bad, just successful. We must always remember to equate success with persistence—not its compatibility with the agents hosting it but how it adapts to maintain its existence.

We define a pattern as good or bad, not because of its self-reinforcing nature but because of the result according to some observer or inhabitant of the environment in which the pattern plays out. In effect, there are no objectively good or bad patterns. All patterns fall somewhere along two axes: the axis of strong or weak reinforcement and the axis of the opinion of those whom the pattern affects. We take the side of the humans, the developers, the customers, and organisations concerning these patterns. But remember this difference: a pattern can be objectively good on the survival axis but is only ever subjectively good on this second axis of benefit to the environment.

Anti-patterns are patterns that have strong intrinsic effectiveness, and we can identify them by the evidence of their negative effect on their environment. Usually, they avoid being placed correctly on the subjective axis, as it affects their survivability when they are identifiably bad. So, anti-patterns aren’t immediately recognisable; they wear camouflage.

It is a stronger position to feign alliance than to antagonise relentlessly. Anti-patterns fake alliance well. They provide small justifications for their existence and so survive limited investigations. Only when we look deeper into an anti-pattern do we see the problems it causes.

Anti-patterns often cause a cycle of repair. A new corner case you weren’t aware of turns up, and you have to fix the fix to the fix. In effect, anti-patterns often get you solving the solution over and over again. I think Christopher Alexander was aware of them but discounted them as not worth documenting concretely. This might have contributed to how his projects played out. Being aware of the flows of value to those working according to the established system may have allowed him to play the game enough to bring a little more light into the world.

Examples of how anti‑patterns work

Negative examples are much better than positive ones. And because the subject is anti-patterns, I can share some examples that explain how they work. This section can be skipped if you already feel you understand anti-patterns but read on if you wish to garner a deeper understanding of the mechanisms of their survival.

Convenience as a defence mechanism

Sometimes, just being easy and wrong is better than hard and right. These anti-patterns are like sweet food and skipping leg day.

Bringing the problem into the code before analysis

An anti-pattern of increased coupling.

Object-oriented code is a response to the difficulty in creating proper abstractions for the parts of the problems to be solved by software. This is why the problem pieces often end up mirrored in the object design. Unfortunately, when you mirror the problem into the data and code of the solution, you introduce a lot of baggage, expectations, and complications.

When objects in code have a one-to-one mapping with entities in the real world, we have brought too much of the world into the program domain. Objects are more powerful when they represent larger concepts. Because objects are used to represent entities from the real world, with all their meaning still attached, analysis of the state of the world becomes complicated and more expensive.

If your language allows you to bring the problem into the codebase, that implies you haven’t been forced to analyse the problem before writing the solution. Most solutions are complex because they solve an ambiguous or poorly-refined problem. So, any language that allows you to represent a poorly-refined problem will not give you feedback on your next steps. Instead, it will enable you to create an ineffective solution to a problem sooner. Solving problems fast will create a feedback loop that implies this approach is better, as solved problems look like progress. But this is an anti-pattern; we know complexity, hidden or not, is the doom of all large projects.

In Domain Driven Design[DDD04], it’s stated that the domain will be revealed throughout the duration of the development. That means the objects, their names and what they mean are not set in stone at the beginning. It is, in fact, the core activity of an engineer to fully understand a problem and remove ambiguity before settling on a design.

Suppose the domain is to change, and the problem will be better understood over time. In that case, bringing the problem domain as it is understood in the first development phase into the codebase invites change at a fundamental level later on. This is good if you have planned for such a major upheaval, but most languages don’t have good object model migration tools. Refactoring tools are good, but not magic.

Last minute creation, or FetchOrAllocate, GetOrCreate, or FindOrConstruct.

An anti-pattern of repository locking.

We encounter the same issues as with the construction of Singletons. When creating the Singleton on first use, we have to lock. When we create an entity on demand based on a unique identifier, we also have to lock. But there’s a difference inherent in locking against a unique identifier rather than a Singleton. When the location of the entity is not a simple globally allocated slot, but instead some dynamic container, we have to contend with locking that container. Now we can potentially block another entity registering to the same container at the same time.

We see here that the issue with last-minute creation into a repository is that it blocks parallel access. This means you can end up with deadlocks if the entity needs to access different repositories to complete its construction. So, what is the wisdom here? First, the problem with Singletons is that they need to lock their location before they can create the thing to put at the location, so that can cause a deadlock. Second, a last-minute creation adds further complications to that when it’s a uniquely identified object in a repository due to it needing to lock the container of the repository and lock against multiple construction.

We can suggest using containers with concurrent append or insert properties to avoid the issues with deadlocks, but it doesn’t solve circular dependencies between different entities, nor does it really solve multiple construction. Those problems seem like problems of usage, not the pattern itself. Another solution would be to have the constructors of the entities not allowed to call upon other repositories until a later moment. Allocate if necessary, but don’t fully construct until used by that which fetches the entity. In effect, prefer dumb constructors.

Obvious truth as a defence mechanism

Best practices that conflict with other best practices. Things that seem obviously true but in fact may not be. Assuming your problem is unique. Acting on common expectations without evidence.

Physical code layout matches logical

An anti-pattern of unnecessary coupling.

We don’t remember anything in great detail if we have only visited it briefly or been away for a while. We are therefore disadvantaged if we need to keep bouncing between different source files to see how the code works. One class per file is an anti-pattern because we have to jump between files to track the flow of messages between objects.

But if we have to bounce around between files to figure out what is happening, is that the symptom of a different problem? Yes, and it’s because the value in some code is the emergent properties of the interaction between elements. So why is the interaction held across multiple files?

In some languages, this is inevitable. Java demands it as part of the language. But in C++, keeping files and classes mapped one-to-one is a cargo cult anti-pattern. The pattern maintains and reinforces itself through We’ve always done it that way but is often at the root of longer compile times and moves some optimisations from compile to link time. As linking is harder to multi-thread, you push some phases of your compilation into a serial bottleneck.

In data-oriented programming (not data-oriented design, but a different, functional-programming paradigm that espouses the separation of data structures from the transformational logic and eschews mutability in favour of a monadic style for transformation), logic can be grouped by the intent. Utility functions are grouped as simple verbs for a system, and complicated functions are grouped by usage patterns. It follows that a developer can read and easily understand these transformations, as they are all physically located near to where they are used.

The real problem is how related classes are so often kept on different ‘pages’. Moving things away from each other when they are related makes it hard to read the flow of the code. Encapsulation is often used to claim the opposite. Nonetheless, the chance a class is fully understandable by its interface is low, which means you must often inspect the implementation. In debugging and maintenance, this is always the case, even in well-defined APIs; you know something is not doing what it claims to be doing, so now everything is untrustworthy.

The physical layout of the code should match the easiest way to read it. It should follow the process the computer would go through. Whenever the next line the computer runs isn’t the next line in the source code, you’re adding comprehension blockers.

Overgeneralisation

An anti-pattern of removing important connections.

Overgeneralisation is when you lose specificity. It’s when you had information you could have used at one layer of the process, but along the way, due to the generalisation of the API, you could no longer pass it along with the request. This can happen by omission of arguments or context, but it can also happen with type sinks. These are places where type information is lost because a common base type is used to transfer the information to the next participant in the communication.

Strings are potent type sinks as they represent many different types of information. In a 2014 talk, Scott Meyers¹ uses examples of filenames, customer names, and regular expressions. The danger of sinks is that they circumvent the type system. You have to remember or name the variables to defend yourself against accidentally using the wrong variable in the wrong function.

All types can be sinks, but some are more likely to sink than others. This principle applies to integers and floats/reals, booleans, and even file handles. A floating point doesn’t have a meaning, but kilograms, cubic centimetres, or Celsius do, and using a bald float ignores that. Files are local, memory, logging, stdout, read, and write. When we let the same variable possibly be any of a set of things at runtime, we can lose vital information that could help with debugging and maintenance or performance.

However, I must repeat: all types can be sinks. Your Kg type might be sinking the maximum payload for a vehicle into a simple mass value, whereas the meaning is payload, not total operating mass. If you use the maximum payload value in the calculation for how many of these you can carry on a ferry, you will be overestimating and the type system will not have saved you.

This is the purpose of Apps Hungarian. In Apps Hungarian, the process for naming required you to prefix with the meaning of the variable, such as Kg_, CC_, TempC_, Px_ for pixels, or Kt_ for kittens. Whatever the team decided was an important distinct type got a prefix. It’s also why we don’t like Systems Hungarian. The prefix there was most usually related to the literal type. A filename was an sz_ type, a zero-terminated string, but so was a customer name. Systems Hungarian was a panacea for the poor IDEs of the time.

Future proofing

An anti-pattern of preparation over valuable action.

When developers suggest building reusable code at the outset, they take a gamble. They bet their code will be sufficiently well documented, discoverable, and isolable to be used as easily as a common runtime library feature. I wouldn’t make that bet. I think it’s better to make the code solve the real problem I have right now. Better still, it’s good to know the odds.

But reusable is good. It’s an obvious truth. So why not aim to make something reusable? What are the chances the code you write today can be reused by some other project in the future? What’s the chance the code you write can be used in multiple places in the same codebase during the project’s lifetime?

The driver for this anti-pattern is compounded by the wonderful feeling we get when our code is reused. We wrote something that was useful more than once. We shipped our contribution in multiple products. We were a force multiplier for the organisation. But we forget all the other times we built reusable software that wasn’t. We remember the good times. We also forget about all the costs of maintaining the reusable but not reused code we wrote all those other times.

To be reusable, code is more brittle and lower performing, both stricter and more generic. Even though it will only be used in one location to start with, it takes on these constraints in the hope of future reuse. We also need to remember that we did not go hunting through the codebase to see if another piece of existing code could solve our problem, so why should we expect anyone to discover ours?

My principle to defend against this anti-pattern is to accept that reuse is a requirement and never intentionally write reusable code—only refactor code into reusable code when the need for reuse finally arrives.

Team growth and company growth

An anti-pattern of overlooking impact.

Teams work best at certain sizes, but successful teams and their leaders can feel like they need more staff to complete even bigger tasks, and their track record proves they are a worthy bet to take by management. So they get the extra staff, which destroys the team’s cohesion, leading to failure. This is an anti-pattern because it’s a recurring pattern of ruin. It would be best if you protected against it. Awareness of the pattern can be enough, but putting physical reminders in place, such as making the spaces for teams only barely large enough to contain an oversized team, can help remind people without reminding them directly.

Wrongly rewarded

Sometimes, the way we reward actions is wrong, leading to the anti-pattern. We create the Cobra Effect, causing problems by not reminding people of our core goals.

Productivity guilt

An anti-pattern of local optimisation.

What often feels the most important is being productive. Developers feel ashamed when not progressing, even if it’s not their fault. Whatever the environment, studio, home, or cafe, every developer aims to produce. Feeling productive is important. We feel more productive when we can go about our tasks as we know best. Strict rules from IT or policies put in place to reduce cost can add friction and shackle developers. The rules interfere with what we value the most.

However, an organisation cannot listen to the desires of the developers at the expense of being on the wrong side of a historic event. Security failures cost lives when they happen to large organisations. They also cost money and time, which goes against the developer’s wish for productivity.

Feeling productive and being productive are not the same thing. A productive developer can be an idle developer. By not doing anything, they are not causing waste and not wasting anyone else’s time. In this way, a developer can help the organisation. Sometimes, the most productive thing to do is to rest, research, and read. Without goals, explicit or otherwise, employees can still find work to do on a project, regardless of how counterproductive their efforts are, because programmers like puzzles. Better developers like making products and avoid creating more work than is necessary.

The difference between a professional developer and a less-than-professional one can often come down to a level of pragmatism regarding what work they don’t do rather than how they manage to do it all. The professional will prefer to do something with directly associated customer value. The less professional developer will choose to do the most interesting work. Interesting does not mean easy. Developers can get caught up trying to solve tough problems that benefit the organisation very little, so they are wasteful but they are not lazy.

Complicated code is cool

An anti-pattern of inattention to global strategy.

There’s a value problem with complicated code. People are proud to have solved a problem in a complex way. They often see little value in going back and simplifying, or when they do, they aren’t provided ample time to rectify the cognitive load. If you go against the grain and try simplifying things, you can be reprimanded for changing things unnecessarily. This is a cultural issue, and it affects all programming in all languages.

This is a problem more prevalent in seniors than in juniors. They feel the code was hard to write, so it should be hard to read or work with. Not all seniors, but many have insecurity issues or impostor syndrome, and that leads to needing to prove themselves—a badge of honour. They wear the badge in the form of a complicated API or being ‘the only one able to debug it’.

The Towers of Hanoi is an example of a system that does not live because it’s always blocking itself. There is, realistically, only one efficient solution to the puzzle. Many puzzles are precisely this: the idea that there is only one way through. There is a breed of programmer that loves this kind of puzzle, and I call them Solvers. Solvers will work through tricky puzzles happily because there’s something rewarding about the challenge of finding a solution or the only solution.

Solvers crave this feedback. Their goal is to solve optimally. With these problems, they can at least be confident when they have found a solution. But even an optimal solution might be optimal in the wrong domain. Think about how you design a housing plot, ensuring you have space for a few cars. You can save space by making a long, narrow drive. But having all your vehicles on a single narrow driveway costs you time when trying to get one car out if it is parked further in. Optimal solutions in space are rarely optimal in the domain of time.

If solving a puzzle or complicated code problem is rewarding, then why would a Solver choose to make programming more straightforward and, therefore, intrinsically less rewarding? There is nothing inherently good about the challenge of making everything fit and work together. Any goodness must come from getting it done. The buzz of a challenge runs counter to that. ‘Solution-finding’ is a craft people can get passionate about, but work is not leisure. So, solving complicated problems is a strong anti-pattern affecting some developers. In fact, some get caught up solving the same problem for years, either over and over or just once to a greater and greater degree, with no end in sight.

Some things we want are self-destructive

These are the opposite of anti-patterns. Where anti-patterns have robust intrinsic but weak or negative extrinsic effectiveness, these self-destructive patterns invert both axes.

These are the self-destructive organisations of elements that won’t stay put unless maintained. Things such as hexagonal¹ architecture don’t come about naturally. They have to be invented and adhered to on purpose.

Things that fall apart when you aren’t actively maintaining them can’t be patterns.

Without self-reinforcement of the configuration, it can’t self-form. The maintenance cost reduces the value of these kinds of solutions. We have to overcome the lack of reinforcing feedback with diligence. This is where we must use our authority and persuasive skills to maintain a good state.

Some non-patterns can self-maintain once started. Quite a lot of pseudoscience is self-maintaining. Each instance of pseudoscience is undoubtedly not self-starting² because, by definition, it is not discoverable from truth or empiric evidence. But note how quickly detractors are seen as the enemy, how evidence is seen as a conspiracy against the science, and how any positive evidence is often blown out of proportion or regurgitated without criticism.

Architectural idioms are valuable because they can provide repeatable solutions to commonly occurring problems. We assume they are idioms because we can’t be sure they are self-forming. They aren’t self-destructive, as idioms still have a mechanism for spreading. There are many things in this non-self-destructive set. They include modern observations such as domain-driven design, microservices, language construction idioms such as the Backus-Naur form, and relational database idioms and their normal forms. There is a huge set of things that may reoccur, but we lack evidence that they are self-forming. Many have tremendous value and provide a foundation upon which future realisations can be made. But many are likely not patterns.

Then there are the self-destructive or exploding patterns. Rules about spending, for example. You cannot save up to be Google, but organisations still try to cut costs rather than increase revenue as a default reaction to reduced profits. You cannot cut costs to become Amazon; you must invest to create value and grow. If your number one intention is to grow, cutting costs is usually a waste of time.

Management

In any organisation that has a production pipeline, you will find that it has a natural tendency to grow longer if you don’t observe the value in waste reduction. DevOps was built on the concepts of the Theory of Constraints and actively fights against the self-destructive nature of taking the obvious next step.

The obvious route for a manager is cutting costs and optimising what they can. However, you can only optimise what you can see, and it used to be that many managers were blind to what to optimise due to their education. Managers would buy more capacity rather than learn to exploit what they already had. In software development, the obvious solution was adding more developers to a project. The Mythical Man-Month[MMM75] addresses this falsehood. After the DevOps revolution, the recognised solution was to reduce end-to-end iteration time so that developers could create value and receive feedback faster. It’s a shame that in the nearly 50 years since the book was released, not all management teams seem to have acknowledged these observations.

The crisis of management alludes to the exploding nature of these self-destructive patterns by way of saying that production processes become worse over time, not because of bad decisions but because of a lack of informed decisions. When we take the default action, the system’s self-forming, self-destructive nature shows itself.

The default action is the action of the unguided system. Management is needed when a system naturally moves away from the extrinsic good state and towards a contradictory but intrinsic good state. Management, therefore, is always needed when the equilibrium of a system does not match the core goals; otherwise, it will always regress to a worse state.

In effect, management’s duty is not to execute the obvious actions but to make the correct actions obvious.

Differences Between Software and Building Architecture

Because the environment defines fitness, we can now explain why software and traditional engineering have such big differences. The nature of the environment of the builder and the end user is always different. But, in software engineering, there are multiple environments and more entities within them. This means software’s fitness is measured in unexpected ways and sometimes seems oddly unrelated to the end user.

In this chapter, I will explain how the environments differ and what impact that has on the developers and the code they write. I will explain how the type of work is different at a fundamental level and how it impacts how we work and what we value in the product.

Environments and inhabitants

In one sense, it is simpler for patterns to be recognised in the real world, as the builders and the new owners of the buildings live in the same reality. They breathe the same air and touch the same ground. The new owners lean against the same walls and pass through the same doorway the tradespeople used when constructing the building. The patterns of physical construction make more sense than those of software, as the same values apply to forming and form. We evaluate the construction environment with the same rules of thumb as we assess our final buildings. This is a key difference and relates to a point that Christopher Alexander would rail against.

Christopher Alexander appeared to believe that you cannot design a building on paper. Eventually, you will always need to do the final designing on-site. There is no substitute for being there. However, when we construct software, we don’t assemble a thing in a place, and often, we don’t resemble the future inhabitants.

With software, we rarely construct into a pre-existing situation. Physical construction builds into the world, with all its rules and regulations and the fashions and expectations of the users. There are comparable examples when you write applications, such as developing for a domain with a dominant competitor. In that case, you have to assess the existing users’ expectations and learn the metrics they will use to judge your new application. But notice that we can only sometimes use our judgement to determine what would satisfy the users of our software. That’s why we have to resort to A/B testing. And the new occupants may have very different values from us if we are unfamiliar with the application.

Builders and end users of physical construction share quality metrics because most of them are human. For software, what makes an application’s user comfortable is not biological but often idiomatic or habitual for that user; thus, it is much less likely to be in common with the developer, whose habits revolve around developing and testing their corner of the software.

Then there’s the construction site. If we compare the two variants, we see a difference. The final inhabitants of the physical product live with the same thing handled during construction. But this is not so in software development. Not so much because end users don’t live within the running software, for that is untrue. They do. They have a mental model of what is going on, and they inhabit the space of the application. No, what is different is that the software engineers don’t work in that space. The construction site is unrelated to the application. The end users don’t inhabit the code. The software engineers don’t inhabit the application (except when testing it). With a physical building, both inhabit the same product.

A split like this lends itself to malpractice because the product won’t show signs of dirty work. The developer’s world can be as messy as they like as no apparent ugliness crosses the divide into the application’s presentation. If a builder were to have tangled spaghetti of wiring and pipes along the house’s ceiling, the new owner would be able to see it and would complain about the potential hazard. With software, you can’t see the dangerous wiring. That’s what I mean when I say there are two distinct environments—one world in which the product lives and the other in which the product is designed, constructed, and produced. So, software engineering is closer to the process of designing a production line that produces goods than it is to architecture¹.

But even factories have standards, right? Well, they do now, yes. But these standards came about because people uncovered potential hazards in their products. Production lines used to cut corners for the same reasons why code is messy now. There was no pressure to work cleaner or safer; often, it was better to reduce costs. Cotton mills and other factories of the industrial revolution were notoriously dangerous places, often producing dangerous goods and byproducts as well.

Now, in software engineering, at least in those places where we write software to meet strict quality requirements, we see standards and processes coming in to ensure the code factory is sufficiently capable of making the product well enough for human consumption. Code safety audits don’t inspect the code; they review the process by which we write it. Inspecting the code would be like checking every chicken for contamination rather than just checking whether the floors are clean, whether there is a rota, and whether the equipment for keeping everything hygienic is present and in good order.

The separation of environments means the environment of code is different from the environment of the product. This separation partly explains why the GoF book[GoF94] lacks UI or UX patterns. Why would there be? It is a book on patterns of the programmer’s environment, not that of the user.

But what does this mean for software design patterns? Architectural patterns are guidelines for solving repeating problems in the physical environment. Does this mean patterns apply to the software engineering environment alone, the user environment alone, or both, or neither?

The answer, I believe, is both. And occasionally, there is a crossover between the domains. Every problem is a problem of unresolved forces in a context. Every environment will recreate the conditions for certain problems over and over again. Every environment will have some naturally occurring wholesome solutions and some attractive anti-patterns. It doesn’t matter whether the environment is that of an application’s user or the code’s author. Every environment where the contents can change and introduce new interactions and usage patterns can exhibit fertile ground for the emergence of patterns.

However, the split environment complicates things. Resolving forces allows you to create harmony in one domain, but if your actions also affect another, you may introduce new unresolved tensions there without being aware of them—and potentially without any way to resolve them without undoing what you have just achieved in the first domain. It’s like a two-sided maze puzzle where every move must simultaneously be valid for both sides.

Unix programs had good user experience due to this domain split theory. You might think it a bizarre assertion, as command line interfaces aren’t renowned for their usability. But I use the word ‘had’ carefully. Historically, they had better UX because they better fit their users and, thus, their environment. The builders and the end users shared tools and ways of working, thus sharing many values on what made a good program. Programmers and scripters inhabited the same domain as the end users. They had common expectations and mental models of how things worked. The tools, programs, and work products all shared the same environment, which could be why the tools worked so well together. Unix wasn’t just a philosophy but also a combination of using the small tools you make in conjunction with others and the collaboration and sharing model, which appeared around this time.

Programming as an environment

Most methodologies treat programmers as a fungible resource. However, junior developers are developers too. If working in the environment requires you to be senior to work safely and make real progress, then the environment is hostile.

Software inhabits multiple worlds; different entities inhabit each environment. Each class of entity has different values and senses of beauty. Sometimes, the inhabitants have a long history with the space and know what is good for them. For example, users know a good UI when they use it as we’re used to using tools with our hands and eyes and getting feedback on our actions.

In other cases, the inhabitants have little experience of their world. Inexperienced programmers must work with source code for quite a while before concluding whether it is good. They need help identifying what is good for them. They must internalise the necessary values and judgements defining beauty for that environment.

In physical architecture, symmetry is an indicator of quality, as is geometry. Any architectural pattern language needs geometry because it’s about physical space, dynamic entities, and their activity. Symmetry and geometry make the unfamiliar easy to understand. Why? Because things with symmetry are predictable and take up less cognitive space than semi-chaotic things.

Code structuring is about creating software with others. It’s not about the geometry of spaces taken up by people in a physical way but about passing work between each other and relieving cognitive load.

When constructing buildings, symmetry can determine where things go. It’s how things indicate their purpose and what belongs beside them. Breaking symmetry points out exceptions. In code, instead of symmetry, we have something equivalent; we have variation and commonality. We have architectural guidelines that define where things belong and their default appearance.

So, breaking symmetry in construction is information for the end user, and variants are information in code. It’s how we decide whether to apply Don’t repeat yourself. Do we have specific information we want to portray? If not, don’t repeat!

Those who thrive

Your code base is an environment. As such, certain types will struggle, others will survive, yet others will thrive. Do those who thrive or survive create a better or worse environment for the kind of people you want on your team? The organisation is also an environment. The ‘org chart’ and the building that the team works from count towards the environment. How you reward the team and handle failure are as significant to the inhabitants as linting tools and source control. Your organisation could spend thousands on extravagant outings and team-building exercises or, instead, listen to its members and spend less by improving access to testing hardware.

Decide based on what you are making. How should you build the environment to best suit the people you need to make it happen? For example, is your project a conundrum? If so, you want puzzle solvers to thrive. But if it’s a user-facing project, you should cater to those who care about disambiguating and iterating over UX requirements.

However, regardless of the project, there are types you always wish to support and others you never will. Some people care about improving things and we should nurture them where we can. But beware those who want to show off how clever they are as that rarely translates into value for others.

Paper trail

In physical construction, it is normal for older buildings to show their age through nonconformity to modern standards. You can say the same of legacy code. You can tell by its lack of tests, usage of modern language constructs, and older or less consistent naming or style.

What does your code say about the people who worked on it? Are they clean coders, or do they write only the necessary code to achieve the goal? Are they quick workers, leaving functional but difficult-to-reason-about functions full of difficult-to-read short names? Just as we excavate ruins to discover more about the lives of those living in buildings long buried, we can learn about the people who wrote the code by the evidence of their values realised in the lines of source in a project.

If you’re unaware of the environment in the code and around the humans developing it, you’re missing an essential set of patterns for productivity.

Construction speed and design speed

The final product of the physical building process is a constructed artefact. We develop a structure guided by a plan and continue to use it in the same space and form once the project is complete. The software construction process is vastly different. In software, we routinely construct to verify even small design ideas.

In software, we compile the final product according to our current design, test it, and then go back to designing. We have an intensely rapid design, construction, inspection, and reaction cycle. Those in physical engineering must be positively envious of this because it enables us to construct things to a much tighter spec than they ever could or perhaps should.

If we worked like this in physical architecture, it might look like the following.

1. We have a design for a bridge, so we want to test it.
2. We launch a fleet of drones to build it, and they complete the work in under an hour.
3. Then, we take a robot truck and drive it across the bridge.
4. We watch and take notes as the bridge collapses into a fireball of destruction.
5. We order the drones to sweep up all the damage and recycle all the debris.
6. We analyse the results, tweak the design, and set the drones building again.

It’s such a fantastic situation to be in. And yet, once we have a design we’re happy with, there’s a nagging feeling it’s only guaranteed to work for the tests we ran. So, we know it passes tests for situations in the domain of ‘obvious’ or ‘required’, but we’re limited to what we think is possible. And that’s scary. Would I be happy driving across a bridge that had stayed standing through a hundred thousand tests with cars, trucks, and buses? I’m not sure. Did they verify against high winds? Was there a scorching day during certification, and did it ever snow? Nobody did the maths on whether the bridge should stay up under such circumstances.

It’s not that we don’t think about what could happen in software, but we are convinced we can’t do the maths for all cases. It’s impossible to think of all the situations software could get into. So, we do our best, write many tests, and hope that’s enough.

Or we go deeper. We can use the computer to debug itself. We can verify APIs with QuickCheck, and model checkers can find bugs in concurrent code we would never have considered. Fuzzers help us find ways to break out ingest algorithms and protect us from hackers by leaving fewer gaps for them to exploit. Using the computer’s unswerving diligence and boredom-proof brain gives us a chance to find these imperceptible hazards.

There is a big difference between development as a construction process and development as a design procedure. The final objects have different qualities. Design development has the guarantee that it works for the intended use but has little or sometimes explicitly no warranties about its suitability outside those strict requirements. How many licenses have you seen where there is a clause disclaiming liability for any problems caused by software usage? Probably more than you think, as only a few people read the end-user license agreement, but it’s hard-coded into many open-source licenses.

We know we can’t run exhaustive tests when developing as a construction process, so we build with tolerances and reject unverifiable designs. But because we’ve done the maths, the final form comes with a 20-year materials and labour guarantee. An actual warranty, where we accept liability for any damages and losses incurred during proper product usage.

Personally, I am not going to buy a house sold under an MIT license, no matter how many unit tests they ran on it.

Inspection does not improve the quality, nor guarantee quality. Inspection is too late. The quality, good or bad, is already in the product. As Harold F. Dodge said, “You can not inspect quality into a product.”

— W. Edwards Deming, Out of the Crisis[Crisis82], p. 29.

Iteration speed is a valuable tool in getting to a good design, but we have to verify we’re using good metrics, otherwise we can fall into a pattern of positive testing. We must not just test that the code does what it should when used correctly but also verify it does not do what it shouldn’t when misused. Here, the ability to construct quickly pays off massively. We can confirm that our tests work with mutation testing—build something different and prove our tests fail, demonstrating our tests add value.

The difference in speed means that our process of adaptation is different. Instead of making things that are wholesome in their space and adapt easily, we make things that are good instances and make easy-to-tweak designs for their production. We value the ability to accommodate new features, capabilities, tolerances or to heal vulnerabilities. So, instead of working with looser materials as Christopher Alexander did, we work with hard, even brittle materials like the strict mathematics of cryptography, comfortable in the knowledge that they can be changed and restructured on a whim.

In software, the tricky part to modify isn’t the product but the design structure. The materials might be fungible, but the value in source code is not just in what the configuration produces but also in the familiarity of the arrangement to all individuals involved in its development.

Home

Home is not a house, dorm, or bed but a feeling of safety—the space to dream[TPoS58]. Home is our comfort and the beginning of each thought. When we are pushed to criticise home, we do not like it. People have many homes in their lives; a workplace or a park can be a home for the role they play in the world. Each aspect of us knows a home. Even if where we live is not perfect, we find one nook that we can trust and fit our most intimate selves there and relax. Programmers often feel this way about code ownership. I wrote it, I maintain it; therefore, it is a familiar home to me.

Sweeping changes are stressful because they make the codebase unfamiliar to many invested inhabitants. I equate this with a messy desk or workshop. When someone helpfully tidies it up, you can no longer find anything. When my parents took to cleaning my bedroom in my short absence as a young adult living away from home, I felt invaded. It was no longer my space. I did not feel I had permission to make further changes. When a code module I maintained for a year was suddenly subject to a series of pull requests making substantial changes and aligning it with a different module, I felt I had to either push back or take it on the chin and recognise the code was never my own. I had built my home on a right-of-way. It belonged to the project, and my familiarity with it was for me alone.

This is and always will be the strange habitat of code. The coder lives in the codebase for so long, and then suddenly, the product, the construction, is accepted. The codebase is vacated. You finally build the best possible environment to work in to solve the problem now it is understood—and with its success, the world is void of purpose.

It not only happens at the scale of the project but also a room at a time as components are developed and finished. All this is true unless you reuse, extend, and maintain the product. But even in iterative product development, there will always be a time when there are people leaving the project. For each of them, they are leaving home—a familiar dwelling and its associated safety.

Inhabitants and motion

In physical construction, the inhabitants and events that play out in buildings are the only factors we can use to create metrics for the value of the building. We can only measure the value of a construction by those for which the building is intended, whether as their place of work, rest, or play. How those events play out, whether they are effectively performed or fit neatly into the space, can be used to describe the suitability of the building.

In code, the end user and their activities are the critical measure. What the user gets out of their interactions is the only metric by which software should be measured. But this is not always the case. Software is purposeful, and whether it can be found and used to complete a task effectively determines whether it is fit for purpose. The inhabitants are the users, and the events that play out are the users’ transactions, actions, and interactions.

How do these values differ? Well, referring to the insight discussed earlier, there’s a big difference with maintenance. The built object needs to be maintainable for physical construction, whereas, for software, the product need never be repaired. Instead, it is the code that constructs the product that needs to be revised. In some situations, even the data can be thrown away, but usually, it’s just a minor migration task, even when wholesale replacing an application. This is quite different from physical building maintenance. We can’t just tear down a whole house and replace it. People keep their stuff in there.

But this is not always the case. With regards physical buildings, one counterexample is a hotel room. If there is something wrong with your room, the hotel can offer to move you. This is effectively the same as replacing the building. On the IT side, there are counterexamples where software must be maintained rather than replaced. The way servers used to be run was ‘as pets not cattle’, so uptime was extremely valuable, and the ability to make changes to the running system was considered a mandatory requirement.

Physical building maintenance is akin to changing the codebase while your application runs. While possible in most programming languages, this activity is unusual in the present climate. We generally restart services or shut down applications while installing new versions. The feature is built into Erlang; you can roll your own in Python, but C and C++ are more complicated. Stefan Reinalter’s Live++ is an excellent example of what can be achieved. But these are all exceptions to the rule. However, not all systems can keep the product in place; some need to replace the whole running executable. Those that mutate their behaviour to achieve change and leave the source untouched are more like physical buildings. Because we don’t reconstruct with every design change, the design should include protection from things that are not yet present.

The natural software maintenance pattern is to tear it down and build it back up. Unfortunately, this transfers into how we consult with the client. Developers second-guess software users and make changes without informing them. With physical development, it’s relatively uncommon. For one thing, maintenance and change costs time and money, and the maintenance will intrude on the physical location, so the client is aware by default.

The other difference is that with physical construction, even if the design is uniform across a selection of buildings, there’s still a chance to customise specific structures. When the land is a bit smaller or lower, or a road bends a little towards the end, we can make adjustments and local adaptations can play out.

When a design is improved, existing buildings are not automatically updated. This is clearly not true with software. Rollouts and updates are now the norm with software. I cut my teeth on writing software for games consoles. When I began my career, consoles didn’t have network connections, updates, or patches. Those games were almost the same as physical buildings. If there was a bug in the game, it would be in all copies and would never be fixed. Today, almost every game over a certain size has what is known as a day one patch. The process of certifying a game as suitable and bug-free as possible is slow enough that a development team can work those extra weeks to produce a new version with significantly fewer bugs. It’s a strange world we live in. Hardly anyone but the testers and reviewers play the first version passing certification.

The software user has a discontinuous interaction with the application. One day, the application will be different, and there is little opportunity to go back. Changes are thrust upon the user whether they like them or not. The money and time they invested in the application are not seen as a reason for the developer to consider the user’s point of view. Instead, the goal is always new users.

As stated earlier, we don’t always use the value of the software to our users as the metric of success. New users are new sales. Sales are money, and money drives the actions of most organisations. Sometimes, there are romantics who believe there is some greater purpose to their work. But even if you are trying to make a delightful and practical tool for your client, you’re only being allowed to by the organisation because it senses your actions are profitable overall. Harsh, I know, but unless you’re in charge of the organisation, such as with some open-source initiatives, then ultimately, it’s probably money pulling the strings.

Beauty and Quality

Patterns can be lenses. They can guide and amplify the process of using your senses for new solutions. They can help you better determine whether the foundations you are forming are promising or poisonous. This sense of the quality of our solutions is intrinsic in us. It senses what Christopher Alexander called the ‘quality without a name’.

Throughout Christopher Alexander’s research, there’s a thread of something that, at first glance, seems to break with science and rational thought. The architect put up many buildings, so when you first learn about his ideas of using feelings and instinct to make highly consequential decisions, you are left confused. On the one hand, here is someone who devoted their life to constructing buildings that withstand the strictest regulations and environmental constraints. And yet, his core thesis relies on human instinct and emotional responses.

We have been taught that there is no objective difference between good buildings and bad, good towns and bad.

The fact is that the difference between a good building and a bad building, between a good town and a bad town, is an objective matter. It is the difference between health and sickness, wholeness and dividedness, self-maintenance and self-destruction. In a world which is healthy, whole, alive, and self-maintaining, people themselves can be alive and self-creating. In a world which is unwhole and self-destroying, people cannot be alive: they will inevitably themselves be self-destroying, and miserable.

But it is easy to understand why people believe so firmly that there is no single, solid basis for the difference between good building and bad.

It happens because the single central quality which makes the difference cannot be named.

— Christopher Alexander, The Timeless Way of Building[TTWoB79], p. 25.

In The Timeless Way of Building, he uses the term ‘quality without a name’ to describe what he sees in the best buildings. In other books, he describes the quality as that found in the smiling of a face, not the face or the smile itself, but the moment of reacting with one. It’s never the building but how it sits in its environment. It’s hardly ever a thing in any sense, but it’s always about configuration in reaction to a context. The quality without a name identifies attributes of relationships more than of the elements alone. But describing it is difficult. Christopher Alexander takes many pages to explain it.

It is never twice the same, because it always takes its shape from the particular place in which it occurs. […] It is a subtle kind of freedom from inner contradictions.

The word which we most often use to talk about the quality without a name is the word “alive.” […] But the very beauty of the word “alive” is just its weakness.

Another word we often use to talk about the quality without a name is “whole.” […] But the word “whole” is too enclosed.

— Christopher Alexander, The Timeless Way of Building[TTWoB79], pp. 26, 29–31.

He lists other words—comfortable, free, exact, egoless, and eternal—but in the end, admits that no single name captures it. The quality is well-described by these words, but it took me multiple readings to grasp the concept fully.

More concerning is how this sense of quality is easily disturbed. We overrule it with our logic, preferences, history, or societal norms. It’s easier to ignore the sense than use it, which is why it took Christopher Alexander such a long time[NoO1-01] to find the right way to express the questions he used to provoke responses employing it. The question, then, is, why did he feel the need to provoke it in the first place?

The quality without a name is that which you detect when the environment is in harmony. The detection is personal, but it is universal in that every individual will be just a little more comfortable and less stressed than if the surroundings deviated from that equilibrium. An environment extremely alien to us, not fabricated by dissimilar humans with different tastes, but outside our sense of normal or regular, sometimes it feels natural and safe. That almost animal-like feeling of goodness in the moment is our instinct telling us the world is okay. Stay like this. We find it in places, objects, people, and communities. And everyone has this sense, and this sense is, for the vast majority, aligned across humanity.

Christopher Alexander ran an experiment that often goes by the name ‘the paper strip experiment’¹. In the experiment, he presented a set of paper strips of seven segments, where each segment was painted either black or white. Every permutation of three black segments was present among the 35 strips.

Over a series of tests designed to determine the perceptual complexity of each of the strips, Alexander had found evidence of an overall ordering. The test results were highly correlated even though each test was quite different in design from all the rest. Without planning for it, he had made a series of tests which where the least inviting to the ego and most aligned with intrinsic feeling.

The tests revealed an empirical order to complexity, but it also revealed something else. After working with the results for some time², Christopher Alexander deduced the wholesomeness and simplicity of these very abstract artefacts came down to a property he had seen in many wholesome architecture projects. The property of sub-symmetries, later formalised to local symmetries, which I go into more detail on in the next chapter.

The quality without a name has many aspects. This was likely the first one recognised and rationalised by Alexander and his team. It’s a property of most wholesome objects. It was a great discovery, one of many to come. The aspects were developed into the properties, transformations, and sequences of unfoldings described in Christopher Alexander’s largest work, The Nature of Order[NoO1-01]. However, for now, we need to concentrate on two questions about the quality without a name. Surprisingly, they have the same answer. Why is this subtle sense so fragile? And why do we all have the same sense of it? To answer this, we must take a path through the world of beauty.

Beauty as objectification of quality

Beautiful code is good. But how do we get from the design patterns of nominalisation or separation of responsibility to the idea that beautiful code is good?

Beautiful code is beautiful only when we consider the viewpoint of genetic evaluation. Its ability to reproduce makes it beautiful. Its ability to survive makes it good. Whether it’s fit for purpose is part of it. Whether it’s an environment in which other things can happily exist also contributes. Companies with bad code tend to go out of business, but it’s sometimes circularly defined. The code is defined as bad because it’s non-surviving; the business didn’t survive. Companies with good code can go out of business too, but that’s a weakest link issue, where an accident from a different domain cuts the life of an otherwise healthy organisation short.

It’s a very circular definition, but it’s just the same as how we evaluate and define good or high-quality for biological systems. We measure a genome’s effectiveness by how successful the organism it generates is at reproducing. If the organism dies, its genome has failed. If you assume poor genes lead to a weaker and less successful organism, you have already accepted the circular definition.

Good code will be relative to its environment, and goodness will be a metric of surviving in the face of competition. And yes, if you are shielded from some forms of competition or challenge, your code will likely be deficient in those domains. Without competition, removing poor performers is nearly impossible, as performance won’t be measured meaningfully. If there is no performance baseline, there can be no performance assessment.

But code is unlike DNA. DNA does not have rational authors. The genetic process introduces changes that are simple and random. DNA leverages the power of small, safe changes by combining existing proven DNA. The reason DNA recombination in sexual reproduction is so powerful is that it selects from already proven actions and sequences. Without combination, mutation only allows simple random occurrences to introduce novel sequences. It’s much more likely for a mutation to represent a regression than an improvement. Combinations are more likely to be variations of existing qualities. Think of it as the difference between the likelihood of forming a new valid sentence by using randomly selected words instead of taking random sentences and splicing them together. The chance of obtaining syntactically correct outcomes is still low, but it’s much higher than with single-word changes, and the result is probably more entertaining.

But how does this apply to code? Well, programming tends to consist of providing alternatives to existing code. Our options come from existing code, memory, or creating on demand. But even new code from our imagination is a combination or mutation of something we have experienced. We make changes that are unlikely to be entirely regressive. And if it is, the compiler or tests should catch the problem before it becomes too detrimental.

Programmers can examine existing code and determine what might improve it. Think briefly about how science fiction authors write about genetically engineered creatures; they always seem to be improvements. We modify crops similar to how we make changes in software projects. Introducing plum pox virus genes into plums to increase their resistance is equivalent to importing libraries into our projects.

What does this mean for beautiful code? Well, the ability to tell what the code does and how we can combine it to create improvements is part of what makes it a better survivor, so that aspect must go towards our definition of beautiful. If we can make effective changes safely, we have an advantage over the competition. This aspect, too, must be part of the definition of beautiful code. Whatever makes the source better able to survive and create more of the same source will define what beauty is.

We can’t personally see the beauty, whichever way we look at this. We do not find the most beautiful code attractive. Its properties can only be recognised rationally. We are not struck with awe at beautiful code. And neither are we aroused by a particularly elegant walrus.

But that makes sense because beauty is something in our genes first, our culture second, and only finally in our individual selves. Our sense of beauty starts with our rawest instinct about a thing. We gaze in awe at cliffs and large buildings or from the tops of mountains or the windows on a plane. These senses of beauty (or fear or wonder) are human. Not Western, Eastern, feminine or masculine. All humans see something positive in a warm glow from the window of an abode on a cold night. But this sense is fragile. We logically override the good feeling if our rational self notices a chain-link fence between us and the glow. If we hear alien language from within the building, our suspicion is raised. This is our self overriding the genetic response. Christopher Alexander wanted to avoid this with his paper strip experiment. His abstract test allowed for the most concrete yet honest response.

Why we think things are beautiful can be societal and personal, but whichever layer you choose, beauty is the objectification of quality in that domain. A beautiful dance is a genetic beauty of grace and motion, a cultural beauty of consistency with a pattern, and a personal beauty if you prefer a particular type of dance. What’s useful for us is to see that the quality without a name is closer to pure genetic beauty, even in chairs and paper strips.

But then, we find ourselves in a desperate position. We haven’t been evolving for the last hundred thousand years alongside code. We don’t have any genetic sense of beauty in that domain. So, we cannot see beautiful code at that lowest level. We can only see its beauty in the cultural (coding standards) or personal (familiarity) sense. We may objectively state that some code matches our cultural norms and that we like it, but we can’t assess whether it’s beneficial. Just looking won’t tell us if it’s good. We must act like genetic processes of that domain, making changes and building unquestioningly before seeing it all tumble down to be superseded by a superior piece of code. We can only verify whether code achieved our goals. We can only loosely estimate how likely the code will survive.

This is why software architects have a Herculean job to do. They have to provide a path to follow while blindfolded. Most will choose safety: they will adjust an existing paradigm to fit the purpose, much like how DNA recombination works. Sometimes, the different pieces work out great. Other times, they complicate and cause problems. But then, that’s information to never do that again, effectively neutering the code so it can’t breed more offspring.

Beauty to the inhuman

A dry stone wall is a formation caused and perpetuated by humans. Humans needed a way to set a boundary, to mark a place and limit the movement of livestock. A dry stone wall captures our imagination because it’s built for a clear purpose and helps us survive.

• Modern architecture is a formation caused and perpetuated by capital ownership, working for hire, and the career maintenance of visionary architects.
• Cell walls are formed and perpetuated through upkeep by protein reactions.
• Humans care, but we are as cattle or proteins to the driving forces of modern architecture.

Christopher Alexander claimed modern architecture led to dead buildings[NoO1-01]. He called it less alive than the timeless way of building. He saw buildings immaturely constructed, but I see buildings built by something at a different scale than human individuals. I see the systems of society and the more extensive system of methods and commissioners of construction. I don’t think it’s dead; I think it’s alive and hungry.

Robert M. Pirsig went to great lengths to uncover a better definition of subjectivity and objectivity, first in Zen and the Art of Motorcycle Maintenance: An Inquiry into Values[ZatAoMM74] and then in Lila: An Inquiry into Morals[Lila91]. But I think even he missed something important about subjectivity because he failed to see people as extensions of the gene.

Subjectivity, in a general sense of some things are subjective, does not exist. The lens through which we view a relationship or the context provides the key to what is subjective. When melting ice, there is an objective amount of salt to use. With food, there’s a subjective amount of salt preferable to humans. For slugs, it’s objective. So, even down to simple things like this, we understand there is the subjectivity of the individual, the species, and the context.

So, when we talk about subjectivity, we must consider the subjectivity of what?

Where Christopher Alexander claims modern buildings are devoid of life, I counter with context. All buildings are alive but not necessarily alive in the context of humans and wholesome human interaction. Christopher Alexander seemed to believe that the artificial existed. But all artificial things were created by naturally occurring phenomena. Humans are natural, so therefore, petrol stations must be natural. We only think of termite mounds as natural because we think of termites as natural. A higher being beyond our comprehension would consider our 20-foot steel shipping containers natural. They may think of them as odd and not immediately understandable phenomena created by the creatures known as humans, similar in some ways to the hexagon grid of the beehive.

We must acknowledge that modern architecture is natural. Just because we fail to understand the goals and why it survives doesn’t make it dead. We need to understand what its environment is and why it is fit for it. What makes it better than traditional architecture in this environment? When we apply systems theory, we can ask: What do we need to change about the environment to encourage the construction of better buildings? What would it take for more wholesome structures to thrive?

Imposing solutions

Modular designs are everywhere but only fit when the modules have no character and where the environment is free of life’s intrusions. What environment does modular design exist in? It has a survival trait of being easy to reason about when thinking about numbers, not people. It does better when fewer people are in charge of spending and allocating resources to do the construction work. So, one environment is where conscious decision-making time is limited. When you need to make sweeping decisions, modular design is easy to see as complete. And completeness is a virtue when you are not directly in charge of the budget.

Now consider coding rules. Many rules we follow make sense 90% of the time. However, there’s almost always a reason to ignore them at some point. Otherwise, we would change the language outright. Instead, we must use our judgement. The benefit of modularity in buildings comes when you need to devote time to applying your good judgement to the design of hundreds of plots. You can use modules and leave the building to those with weaker judgement because you can trust they can’t do too much damage. Coding rules are there for when you lack the capacity to think about the virtues of many sections of code. You select a set of rules that embody the majority of your principles and lock the developers into producing code according to those rules. Now, you can at least be reasonably sure they won’t deliver a load of garbage if they follow them.

Pervasive modular design is quick to build, dead, and dull. However, it’s only dead to the inhabitants of the buildings. To the environment of countrywide housing planning groups, it’s a natural fit, relaxing two opposing forces of costs and time while resolving a homelessness crisis. It’s a beautiful pattern to the system of government spending. Coding standards align developers and bring about a common baseline of quality similarly. It’s a way of saving energy and lowering the number of decisions people need to make in a decision-making-heavy task.

Cost of uncertainty

In conclusion, modular elements are a theoretically good solution to the problem in the abstract domain of budgets and spending. It isn’t easy to obtain numbers that show the costs and benefits of non-modular solutions, so we promptly discard them as certainty is more comforting. Standard practice states you need an architect to design a house. If we tailor each build to the environment, then clearly, the price will spiral out of control. Again, when you think in theoretical terms, it’s obvious you can’t have bespoke housing for a million individuals. And yet, that’s precisely how the world worked for a very long time.

What about coding rules? In almost every programmer’s career, they will likely remember a time when they didn’t have them. Some will think back on that time fondly because of the freedom. Others will think about the suffering and the pointless bugs caused by not taking obvious steps to increase clarity. But, 20 years on in my career, I still decide on a per-project basis whether I will follow any rules or try another approach. Sometimes, I find no real benefit to a rule; I gain by avoiding it. By not following rules, I often also learn why we have them. By experiencing and gaining wisdom. Oh, painful, painful wisdom.

So, who’s benefiting from the coding rules? Whose costs are reduced and needs met by these rules? Usually coders, in a sense that they get work done faster, rework less, and can work with others with less friction. But the organisation benefits too. Coders will primarily get to do what they want regarding how they arrive at a solution, which means they aren’t affected by the system above like it is with the government benefiting modular design. The most durable rules are those that make coding less wasteful. In that sense, beauty is to be found in eliminating decisions and the time consumed when verifying them.

However, we built a million houses before modularity gained traction. They were constructed with attention as a million individuals made decisions. People had the time and invested it. This is a connection between coding rules and modular housing. Coding rules are there to limit the number of decisions we are required to make before we finish constructing. There are many more undecided points in a software project than in a physical construction project because the effort in a software project is 99% design and almost none in the construction. So, for me, flexible, living coding principles, idioms, and quality guides with examples of how and when you can ignore or adapt them are some of the most beautiful elements of modern software development.

Beauty in the product, not the process

Even though the code in DNA isn’t beautiful, its product is. The beauty of the product lies in the eye of the beholder. The beholder bases their metric for beauty on how much the product’s existence helps it succeed—the particular contribution is irrelevant, whether food, mate, or secure abode.

The quality of DNA is only visible once the organism executes its instructions. Only the outcome of growing as an unfolded sequence of decisions and actions on materials can reveal the true beauty. The product does not measure beauty directly. Implanted into organisms are heuristics for whether something is relevant to their success. These heuristics are the senses of beauty.

We may find the helix elegant to view and the processes of the cell captivating, but these are not beautiful in the sense we are looking for right now. I will explain this, and cakes, later.

DNA expands into an organism based on the organisation of the cell that initiates the process. The way a cell divides and changes behaviour based on proximity to other cells is a complex dance of interaction and contextual behaviour. Christopher Alexander called this step-by-step but analogue motion of change unfolding[NoO1-01]. Even when they aren’t biological, such as with buildings, the unfolding process can be applied by someone interested in starting small and designing outwards from a point. They can adapt, split, extend, and differentiate as the space reveals what they should do next.

The process of evolution affects the choices of the cells doing the unfolding, not often the unfolding itself. DNA code changes, merges, splits, and splices. How the cell replays that code into protein production is hardly ever impacted. Unfolding as a process—cells splitting and responding to their context—must also have evolved. But it’s fundamental. So, it behaves as part of the larger environment upon which evolution plays out. The unfolding process may seem natural and beautiful to us, but it’s uniform across the domain of almost all living things, so it cannot by itself confer advantage. When everyone is literate, literacy is not an advantage. However, the reason why we humans appear to have the upper hand among the animals is down to this very point. We have the power to elevate our unfoldings into new domains.

Beauty is a value judgement by survival machines. Applications need to be beautiful in this domain, so you often see people talk about an application being good or bad, and they can often point out very explicit aspects that prove their point. However, sometimes they drift away without knowing what they dislike about it. That can be the effect of a more profound sense of beauty. Our users will love our programs or hate them. They will prefer them to our competitors’ programs or not. But, as we learned earlier, code must be beautiful in a different domain. We get trapped in destructive code by trying to apply natural beauty value judgements. Remember, we can’t evaluate code by looking at it, as we work with different laws of physics.

Beautiful code won’t look pretty, but it will rapidly make beautiful products. It will create products faster and with a higher survival rate than the competition. That’s the basis. Not the process or how we store our decisions and progress but the ability to safely recombine, adjust or improve, or eradicate waste. Beautiful code is all about maintaining the development environment. No matter how aesthetically pleasing your code is, if the product is low-performing or not novel, capable, or quick to market, then the code is not beautiful.

You might think this means we can declare dirty code, spaghetti, balls of mud, and all sorts of wacky-looking codebases beautiful. And, in a way, that’s correct. However, a very low correlation exists between a coding environment producing good products and it being laborious to work in. Some rough-looking codebases are still around, delivering a valuable service in their niche, but how often do they change? How often do they need to change? Do they have competition? They are not apex predators; they are the earthworms of code.

Environmental fitness

I have a theory tying all this together. I don’t believe there is some luminous ground (Christopher Alexander’s term for the inherent beauty in forms), and I don’t believe determining the quality of things is a uniquely human pastime. I firmly believe quality is relative, but relative to something we cannot help but take for granted.

I am a staunch believer in the power inherent in the evolutionary process. Emergent complexity is natural and explains many more things than we even recognise as inexplicable. I see the impact of selection on television programs, CPU design, the rise of social media, and the origin of art. It’s not surprising to me that it impacts here, too. So much is affected by the selection process that to remain uninfluenced would be unusual. The revelation is not that it is affected by selection but how it relates so deeply.

Evolved species are survival machines. To survive, they must do better than others or at least not do worse than the majority. This selection weeds out those less capable of surviving by letting them die off. Remember, it’s not survival of the fittest but eradication of the unfit, so the system maintains variety. When you have a large variety, you have to build senses to detect the best for you in nuanced ways.

To explain my theory, I need to build a picture of what happens when you have a universe of selection and variety. I wish to introduce a thought experiment involving a species that lives on berries.

At first, the species could not distinguish a good berry from a bad one until long after they had eaten. They only knew the berry’s goodness by how much energy they had the next day. The species evolved when some developed the capacity to discern berry quality by taste. The tasters quickly outnumbered their tasteless ancestors. They evolved again when some began to discern by sight. After that, those who chose by sight were quickly outnumbered by those who could remember where they last saw some good berries.

The final evolutionary step happened when some of the species had inklings about where the best bushes might be. The feeling wasn’t magic; it was a genetic tendency to look in lightly wooded areas near water. It might have been a general preference for the look of trees, the sound of water, or the feel of the air. But when hunting for new berries, those with inklings were more likely to find berries than those relying on memory and hunting without knowing where to concentrate their efforts.

This is my theory of quality. Quality is an indicator of future value. Quality is an evolved inkling, a sense that picks up environmental indicators without committing to recognising them directly. We like seeing mountains and valleys, as they could provide protection. We fear the roar of a lion. We turn up our noses at the smell of rotten meat and salivate over the aroma of baked bread. These are all reactions to a potential future. None of these are reactions to the things affecting us directly.

I want to be very clear on this point. A lion is not a threat. A lion that is hungry and aware of us and how much meat we are made of is a threat because it intends to eat, and then the future is a lion ending our lives to satisfy its needs.

Putting our hand on a hot stove is not an immediate threat. Rationally speaking, our hand burning in the fire is not affecting our genome and only concerns what our genome produces: us. But we react to the fire because genes are instructions for assembling a being that can feel pain and respond to situations where its continued existence is threatened.

The sequence of instructions in DNA drives us to ensure the safety of the instructions in the DNA. It describes a process to create an entity that can tell what is favourable for it while conserving energy. That is quality. It is our reaction to things, driven by our configuration, which is itself driven by selection, which is in turn driven by the environment.

If selection defines quality, then quality is about survival. If being able to detect what is higher quality leads to survival, then why did Christopher Alexander’s paper strip experiment lead to a strong bias towards some patterns of black and white colours looking more coherent than the others? If patterns of black and white squares on strips never turned up as a fitness test in nature, then why do I think this bias is related to evolution and our genes?

I believe the strips are a mimic, like the many non-poisonous insects wearing false black and yellow stripes. The pattern recognition built into other creatures defends these less aggressive insects. Mimics don’t have to be about stripes or even animals. Mimicry is about producing the same phenomena as another source to reproduce beneficial behaviour in the beholder. Stick insects mimic leaves, and cakes mimic fruit. See, I told you I would explain cakes.

The paper-strip pattern harmony is an accident of overlapping domains. The strips of black and white patterns were an abstraction. The arrangements don’t signify anything, but our instincts still react to them and induce a feeling. Our inkling systems respond even when what we sense is not natural. We prefer things with symmetry because, in nature, asymmetry typically indicates damage or inferiority. We can trick our senses into having feelings about things that aren’t good for us, such as sweet, salty, or oily foods.

Before, you may have complained about my statement that DNA is not beautiful or that the process of molecular recombination is not pretty. I hope I have explained why it is not an honest beauty. It exploits our senses, tuned to a different purpose.

Environmental fitness affects more than just the real world. It affects any domain where there are variations and death in any form. Some people refer to this in terms of the market deciding the price. It’s what others will be talking about when it comes to creating artwork and having to kill your darlings. If something isn’t adequate, it will either be culled or not culling it diminishes your fitness.

When we talk about environments, one particular environment comes to mind for software engineering: the codebase. Who lives in the codebase? Does the computer or the compiler live there? To know whether something lives in an environment, you must first determine whether it can die. In the case of the compiler, it’s unlikely it’s inside the code environment. It might be within the larger setting of the organisation if there were a willingness to change the programming language or vendor. But realistically, it’s more environment than inhabitant.

We can delete the source code. So, it undoubtedly lives in the environment. But as in a natural setting, code is also the environment for other code. It makes the environment inhospitable to other code. Do people inhabit this environment? Some do. Their reputation and ability to get work done relies on its structure, so their career and ability to effect change in the environment are themselves impacted by the environment.

How this helps

There’s a lot going on in this process. We need to step back a bit and ask, how does this help us understand design patterns? First, we can recognise patterns as something akin to features of an evolved species. They are documented inklings. Second, we can use fitness to define whether patterns are high quality. Third, we know we can look for patterns in any environment, which means we need to recognise which environments we’re operating in.

We can assess whether a code configuration is healthy based on its fitness with the surrounding code, business practices, and tools. We know some developers will perceive quality differently due to their wisdom about a particular configuration’s impact. This wisdom indicates how well the developer understands the environment and its complexities.

But more usefully, we can now question the quality of the outer environment. Consider outer environments as compilers and tools, the operating system, company policies, or the hiring process. Any environment influences how we measure quality, whether in the code or the developers writing and maintaining it. The fitness of an environment affects its output and the evolution rate for the entities within. So, we can judge it. Anything we can judge can be removed, so we can find patterns here as well.

An environment competes against other environments when entities can migrate between them. You can’t quickly get a drink in the desert, but you can migrate to a wetter climate. You can’t always follow best practices at one organisation, but you can find a new job. You can’t write expressive code in your current language, so instead, you can write a DSL. If you’re aware of other environments, those environments now exist in a meta-environment and begin to jostle for fitness because an environment without entities is a dead one.

Positive only

Rather than inspect all patterns, including anti-patterns, let’s concern ourselves with how to find and use the best positive patterns to write better code. Finding them will be difficult because we do not have the right instincts to tell good code when we see it. Great or perfect code can look like a mess to our eyes. We cannot gauge it because it belongs to a world with different rules of survival.

None of our existing instincts apply, as those were developed in response to the rules of physics in our three-dimensional world plus time. The world of computer software has a very different number of dimensions and a very different set of laws of physics. Therefore, when I ask you what type of feature is attractive in core code, you must rely on cultural or rational evaluations.

We want an innate inkling system for good code and bad code, but we don’t have one. We almost have the opposite. Our inkling systems were developed to appraise the physical world, not that of software design. Our instincts prefer symmetry and repetition, which do not relate to quality in code.

Programs are not buildings, art, or Turkish rugs, but something unfamiliar. Programs are more like plans, laws, or recipes. Programming languages reflect our expectations or judgements. We need to find the properties supporting our goals.

The source of beauty

Organisms evolve a sense of beauty as a mutual adaptation present in the expression of the wielder and the appraisal of the beholder to promote survival. The earliest bees had limited concern for flowers, and the flowers didn’t prioritise bees either. Over time, their appraisal and expressions co-evolved into an unbreakable bond.

Our reaction to excellent code is weak. We need to accelerate the process of recognising its beauty. What will code look like in a million years if we consistently select code that keeps us safe and productive?

Most patterns will make sure any problematic code is removed or repaired. They would suggest code forms that are easy to mend or never need maintenance. The patterns would reinforce exponential growth and force multipliers, making further development easier or helping developers decide with confidence. They can be better processes, revealing the unknowns earlier in a series of development steps.

In this way, the Agile Manifesto[AM01] looks like a hypothesis for, or a description of, software development’s laws of physics. The manifesto is not a process but presents the metrics for selecting good processes.

Beautiful code

Code is more like prose, so it is less well-defined concerning survival. We react to bad poetry, but code is more like non-fiction. Its value comes from unambiguously revealing the answer to questions. Code needs good form, but we need to evaluate it in an alien way. One way to think about code is through our closest analogy in biology.

Business logic or gameplay code follows the same formal rules of beauty as DNA, as it constructs the final form. It must be simple to safely recombine, splice, and experiment with. Changes ought to affect the final form in well-defined ways—they must be safe and cheap. Experiments must be non-destructive and isolable. Our inkling should align with enabling confident, quick changes.

The metric of quality is different for core code, framework, platform, or engine code. We may wish to follow the same beauty rules as the cell construction and replication engine driving the unfolding process. These foundational components must have robust, error-free mechanisms and be extraordinarily reliable. Experiments in business logic can only happen on top of solid foundations. We should define goodness by the certainty of behaviour. Unit tests will rule and deny damaging changes from escaping into the world. This kind of code must have proof it works as intended, meaning all code of this type must document its intention.

Beautiful processes

DNA is an environment in an environment. It is a peak fitness form for life on this planet. But that only means DNA is a good environment and was better than the rest when it first appeared. We may never know what came before DNA, but with code, we can see multiple environments, languages, and development practices. One may emerge and dominate the way DNA dominates, but it’s hard even to name a leader today.

We could consider Agile to be leading at the organisation layer right now—or at least the real-world manifestation of the term. The one put forward by those who signed the Agile Manifesto is reasonably well defined, but the diluted term is faring better.

Agile, as it is, is winning as an environment in the environment, but it lacks a definite boundary in its current form. It’s hard to say what is Agile and what is not, which is itself a self-defence mechanism. This makes it difficult to differentiate it from the competition or even identify whether there are any competitors.

Good quality now, bad quality later

At the time of writing, there’s a general opinion that code quality comes down to a set of features. It often presupposes an object-oriented model, which is itself an interesting point. One version of this list might look like this:

• Cohesive
• Modular
• Loosely coupled
• Encapsulation
• Separation of concerns

I feel these are secondary attributes; they are just our current judgements on what leads to good-quality code. I prefer to think in terms of how you might appraise these attributes. Think about a codebase that follows or doesn’t follow one of the principles, then ask yourself these questions:

• How quickly can I debug code written like this?
• What if I was not the author of the code?
• How likely are changes going to conflict when working as a team?
• Does this style of code reveal errors early or hide them?

And now, remembering that the quality of code is judged finally by the environment, we realise these metrics are a kind of fetish. Some developers worship them for their magical powers. We must define good quality by the properties of that which survives. The code’s quality must relate to whether it helps us or our organisation last a long time. That will likely mean metrics for whether it can be easily verified and maintained should hold more clout than whether it passes some objective structural analysis.

As an example, there was a recent post on Twitter (recent as I write this) about a Dutch government codebase for some medical software. It included a way to print out a percentage on some character-based output device¹. The code is immediately readable but unexpectedly verbose for what it does. Any experienced developer would wince at it. However, it survived through whatever processes it went through to get there. So, is it good code? Objectively, it is, as it survived its environment, even if hardly anyone would be willing to claim they wrote it. But it says more about the environment than it does about the code.

Metrics for the future

SOLID is a collection of five principles for object-oriented software design, espoused by Robert C. Martin and first published in his 2000 paper, Design Principles and Design Patterns. They provide some difficult-to-calculate metrics, but they are metrics.

The first metric, the single responsibility principle (SRP), is usually interpreted as the quantity of code duplication. Most paradigms would agree in declaring this to be a useful indicator of quality code. Duplication or repetition is a positive feature in physical construction, but we can quickly rationalise why it’s bad in code.

The fourth principle, interface segregation, can be thought of as a measure of how much more API you reveal than necessary to your clients. Many other paradigms do not need this metric as they don’t naturally suggest over-advertising capabilities.

The open-closed, Liskov-substitution, and dependency-inversion principles each help us detect object-oriented code which is harder to maintain. We can apply these metrics to object-oriented code and declare it solid or wanting. In that sense, they are the metrics for now, while object-oriented design dominates the programming world. But what will be the metrics of our future?

A strong candidate is the use of immutable state to provide protection from the issues of concurrency as they become ever more relevant to regular programmers. Another might be data unencumbered from meaning, with principles taken from data-oriented design. Full traceability through documentation and process artefacts could surface as an accepted quality metric, as it has through ASPICE². Others might consider data-flow testing to be a good metric for quality or at least hygienic code. Developers who use Rust or Python can already write test code in their documentation, so will that become a quality gate?

Should we start including metrics for quality outside the language, such as build times and response times to exploits? Given how connected the world is, can we accept code with a guaranteed turnaround time for exploit fixes measured in weeks? Some binding agreements already specify a response time.

All the things we think of now as good metrics might be because of our presently accepted paradigms. There are things we put up with now because that’s just how it is. In the future, we will see them as mistakes. We should know better already. Is there a way to move forward with these metrics faster? To find them before others and make better, higher quality code sooner than the competition?

Living things are not complete

There is a difference between a project being complete and a building being complete. I picked up this distinction from Christopher Alexander’s later works. He never says it directly, but the consistent recurring theme of generative production, repair, and improvement leads me to a further conclusion. The right approach to building never leads to something that is finished. We can complete a task or step of creation or repair, but no building that is made to be alive can be finished because change is inherent in a living and adaptable building.

Stewart Brand talks about this subject in the book and TV series How Buildings Learn[HBL94]. He references how long-lived buildings change at different shearing layers. Buildings change at multiple scales of size and time, from the location down to the arrangement of furniture. Buildings adapt at these scales, or they are razed. In effect, the buildings that prove unsuitable for adaptation are selected for culling. Buildings that cannot change to accommodate the needs of their residents will be removed.

The way I see it, the difference between living things and products is that products can be finished. A house or home is not a product; if it is, it won’t be a good one for future generations. A town is not a product either, and it would not be good if it were built like one. You only need to look at the usual problems with new towns in countries where old and new towns exist side by side, such as the problems caused by the suburbs in countries where relocated families now all depend on cars.

A product is used and enjoyed but ultimately kept as is, archived, cast off, or recycled. Generally, we don’t adapt products to new uses. I suppose this is why we recycle more than we upcycle or repurpose. We can mend a bucket, a pair of glasses, a car, a fence, or a shirt. But when something adapts to a new purpose, it’s visibly no longer what it was. A form that welcomes adaptation is a living form—a form where growth and change are part of its long life.

Living things are in a constant state of preparedness for adaptation. These are the qualities of a healthy code base, person, or building. The final product of a project is a codebase that can produce a product for the customer. We do not modify the products; we modify the design. We adjust the steps the compiler takes or the code that is interpreted. The living thing is the codebase, and only the codebase will be repaired or extended. The design is the structure and the materials out of which an instance of the product spontaneously materialises. Thus, the design of a codebase has two qualities: the capacity for change and the capacity to produce.

Buildings are inhabited by the builders while they are constructed, but they are later handed off to the inhabitants of the building. With source, the programmers inhabit the blueprints of the product, the building is built by compilers, and the users inhabit the deployment of the product. This strange mismatch reduces the efficacy of comparing software architecture and building architecture.

Resilient zombies

From what I have read of them, both Christopher Alexander and Helmut Leitner (of Pattern Theory[PT15]) appear to think artificial things can be made alive and living if and only if they are produced in a specific way. A living thing can emerge from successive alterations and generative processes at the most local and personal scale. They argue that the aggregate power of organisations or wealthy individuals requires pattern theory to guide the short-interval or iterative creation of living structures by applying these generative processes; otherwise, they fall foul of dead design.

Unfortunately, I don’t believe you can simply explain to money how it should behave. You must find a way to join pattern theory to something powerful organisations already value before they entertain such ideas. Wealthy individuals will want status symbol constructions, but by their very demand, they deny living structure. A well-used and loved old farmhouse is full of life, but it’s not of any value to someone looking to build a status symbol. Making sure your skyscraper is ready to be converted into something new and readily adaptable to changing circumstances doesn’t sound like something a business cares about. Investing in being easy to repair and adapt to changes in the surrounding environment is a far-sighted move few in a position of power would exercise or even give a moment of thought.

I doubt living buildings and living codebases are possible when you have egos and status involved. The best code is written by many people over time, all working without ego, spotting each other’s mistakes and collaborating on large-scale migrations from one good equilibrium to another.

Fundamental Properties

The journey started with Notes on the Synthesis of Form[Notes64]. The book showed a process to inhibit complexity when developing architectural solutions. It reduced the task of constructing a village from impossible to a conceivably possible project. But, the most significant outcome of the work was not the development process but the concept of patterns. They pervaded his subsequent books and the software industry.

However, the development of the pattern language process revealed something else. Christopher Alexander stated that, even when publishing A Pattern Language[APL77], he was aware of somewhere between 12¹ and 16² of these fundamental properties of forms. They kept appearing in the patterns of which he was most certain.

His most extensive work by far, the four-volume essay, The Nature of Order[NoO1-01], contains much on the concept of properties. It’s the main thrust of the essay, discussing their existence, value, interpretation, and limits, although not directly announced as such.

Why are the fundamental properties missing from so much of the available material on software design patterns? To understand the answer, you first need to understand the fundamental properties of forms and how they work.

Before discussing the properties, I need to state more precisely what the properties are of. They are properties of the forms of compound objects. They are properties found in patterns of architecture because buildings are compound objects. They are found in other things too, but Christopher Alexander mostly talked about these properties as being present in nature in living things, in the construction of buildings, furniture, and other objects with which we live and enrich our lives, such as teapots and cups, decorations and paintings[NoO1-01], and also, and in great depth, the designs of Turkish rugs[AFo21CA93].

The Nature of Order first describes the properties and later redescribes them relative to nature. Only in volume two[NoO2-02] do we find a discussion on how they come about. The transitions between forms with good properties are described therein as structure-preserving transformations.

This transformation aspect is the process side of the process and a thing of the properties of forms. Given how strongly I feel about how contexts and forces should drive patterns, I also believe the properties of forms should have a description starting from the forces that would lead to their presence. So that’s what I’ve attempted to do.

Rather than, once more, recite the properties as solutions, I attempt to produce a novel summary. Starting with what stresses would induce a need to take the structure-preserving transformation, I present the transition and what the form looks like both before and after. Just as a pattern should start from a position of an unresolved problem and move toward a solution, these properties of form follow a similar relaxing path. However, not all properties of forms are transformations, so in some instances the description has to fall back to explaining what they are and how they come about.

If you already know the properties and are not interested in this different approach to describing them, consider skipping to the section on colour, where we’ll get into the reason why these fundamental properties didn’t land for software engineering.

When an identifiable design element has become too large, it can need splitting. When the shape of a design starts to become too complicated, it can be better to make it a compound of smaller parts. You can turn a more prominent or complex element into several smaller components without weakening its identity in each case. The new features will be healthier when they maintain excellent scale ratios with their neighbours.

A good design often has multiple levels of scale within the hierarchy or web of interconnected elements. These levels must be well proportioned. The scale relationship is between neighbouring sub-elements in the larger design or direct descendants in a hierarchy.

When the subdivision occurs, some sub-elements will strongly support the meaning in the outer element. Some will help it less, even though they are crucial, because not attending to these differences in relevance and scale can lead to designs that feel off-balance.

When designing characters for computer games, animations or graphic novels, characters may look drab if they are too regimented in their details. The vibrance and sense of life immediately increase in the example, where the sizes of each defined part differ but not by too much.

We often see these cascading proportions in older buildings, furniture, or artwork, but not so much in modern creations. For example, look at a modern bookshop or library. You may find all the square spaces are the same size. Modular and regular with no variation of scale. The ordering of the books is more important than goodness of fit.

This property is generally missing from modular design due to the inherent nature of mass production. Modules tend to come in a small number of standard sizes and fit together in columns, rows, and grids. It’s efficient in terms of time to think and come up with a design, but not always an efficient use of space.

Observe the furnishings in an older library or house and you will see shelves of different heights and widths. Even the ubiquitous Swedish furniture item, the Billy bookshelf, has variation in scale with its alcoves. There’s a practical reason for this: books themselves are different sizes. Levels-of-scale has value in simply allowing things to conform when their scale is relatively similar.

I appreciate this observation. Accommodation for all does not mean dropping to the least common denominator but instead offering alternatives. My bookshelf uses a modern modular shelf design, but the modules have the local flexibility I need. I can accommodate all sorts of different book sizes and the occasional radio-controlled vehicle or pocket electronic device.

The well-performing scale proportions all roughly fall within a set range. Christopher Alexander states the most comfortable scale ratios are between 2:1 and 4:1 at the greatest[NoO1-01]. Think about the sizes of rooms in your home. Nothing is 20 times as big as its neighbour. I also think there’s a lower level to these levels, something like a 3:4 ratio. These pleasant ratios must be pronounced differences. If the difference is only slight, it does not appear to be an intentional effect, just an irregularity. If it’s small enough, and repeated throughout the form, say less than 1% difference, it’s a sense of flexibility in the realisation. Perhaps it is just me, but at ratios of between 4:5 and 7:8, the differences look like mistakes.

When things don’t have these ratios, they can feel a little inhuman, such as when there are giant single-pane windows with thin frames, it can feel like you are in a goldfish bowl. You can be alienated from the outside, even though you literally see more of it than with a smaller, better-proportioned window. When you see small fasteners on large pieces of wood, it can feel like it’s there as a temporary measure while work progresses. Things feel unfinished.

In a form with comfortable levels of scale, you will often see substantial borders or things framed in gentle steps of magnitude. You see it in buildings with dado rails and skirting boards. When the scale is too extreme or not significant enough, it looks strange. We also see it in books. Sometimes, the text or headings are the wrong size for the script beneath. Images might be the wrong size for the layout of a page or the quantity of text it shares the space with. However, a well-constructed page can be a pleasure to view, even if you cannot understand the language of the text.

Levels of scale is the property of good proportions for different elements in the same compound. You can find good and bad examples in font design, website and page layout, cars, and consumer product design.

Sometimes, scale helps identify an area as separate. When enclosed within a larger space, a scale difference provides further meaning to a division. A couch or half wall placed well in a room can divide it so that we give each side meaning—living and leisure against eating. One is a world of softness and relaxation, and the other is a world of utility, quick to clean and a space where we prepare for duty. If these spaces were the same size, if the wall were directly in the middle, both areas would feel wrong. One takes precedence in your life, so reflect that with which is given more of the volume.

Property 2 — Strong Centres

Strong Centres is introduced in The Nature of Order, Book 1[NoO1-01] on page 151.

All designs need an identity, a way to say what constitutes the design and what does not. Where the design ends and the rest of the world begins. But not all these beginnings and endings need to be definite. Boundaries and borders also delineate the form, but identifiable elements and parts of a whole design do not need literal lines around them.

When a design seems to have a weak form, it could be the centres are not as strong as they need to be. Centres are always already present in a form, so this is a property which is not introduced as a new element but one where the strength of the centres are developed. Occasionally, recognisable forms are waiting in the wings but cannot emerge without support from neighbouring elements. But defining weak centres is hard, so I shall describe the strong ones first.

The property of strong centres is not so much a resolution of forces but the basis upon which everything else rests. It’s the atom of wholesome forms. Except, it’s not atomic because atomic means indivisible, and strong centres are frequently divided or overlapping as you work your way down the hierarchy.

The overall compound comprises a set of cohesive, identifiable elements containing recursively more cohesive elements. But, just as people belong to many different groups, so can some design elements manifest as parts of various centres in the same compound. These centres are the discernible elements. If you can see the shape somehow, even by negative space, then it can be a centre.

A strong composite form has to be a harmonious collection of centres. Each sub-form should be a complete and unfolded element in its own right. Strong centres overlap, and the overlapping is itself often a centre, but when things intrude rather than support, they break down. If you can’t effortlessly draw lines around things and characterise them as separate elements, then the form might not have strong centres. In a good design, everything should be a centre, and a strong one at that.

Strong centres are those reinforced by the other centres around them, supported by multiple aspects simultaneously where possible. They are part of a sequence of things, a good relative size, part of a border, or the vital quietness offsetting the noise of a neighbouring compound. Strong centres, whatever they are, are secure, identifiable, and stable.

You can use weaker centres to emphasise a strong centre, but weaker does not mean weak. Weak elements might be unbalanced or skewed, look different or appear original for no obvious reason, or some other weaknesses of relationship with their neighbours. Some centres can be allowed to be weaker because they are the elements at the edge where they have to interact directly with elements from a different outer compound. Others might be strong locally but perhaps have been asked to give up some strength as part of a roughening process to relax a more critical centre.

Strong centres are reinforced by other centres, from within or without. Weak centres are those that don’t have good relationships or are ill-shaped. Now, let’s look at an example of weaker centres.

Many centres in this design are weak or weakened by their neighbours. I adjusted three aspects to show how small the changes need to be.

• The towers with their straight sides don’t lend any weight to the structure, so they weaken the whole castle.
• The straight sides also make the structure look like it’s failed to be symmetrical rather than succeeded in having a bookended design.
• The placement of the windows precisely halfway up the towers makes a false symmetry where none is required and creates equal space above and below, but it’s not completed with an equal-sized window, so it looks awkward.
• The caps on the towers touch the top of the main body, not only detracting from their purpose in the design, but also weakening the main body by giving it two more sides without literal corners to define them.
• With the caps touching the top of the main body, the space beneath the outside edge doesn’t feel consistent with the interior.

If you can detect these weaknesses, you can strengthen the complete design by improving the smaller centres. Each act need only be small to create a significant effect. I detected five failures affecting over seven centres, all from only intentionally damaging three elements. What do you see as weak in my attempt at a strong-centred design? What latent stronger centres can you bring out of the castle image?

Property 3 — Boundaries

Boundaries is introduced in The Nature of Order, Book 1[NoO1-01] on page 158.

As elements of a form become more detailed, new elements grow within them. Forms increase in complexity by seeding from within. This naturally leads to some of these inner forms having very large boundaries. As the forms grow, their boundaries do not deteriorate, for they are part of why the inner form is successful. Instead, these large boundaries are reinforced and remain part of the overall compound.

There are always edges to things: where they end and the rest of their world begins. When objects have an inside and an outside, there is a literal boundary. These boundaries can be strong centres and have significant presence and scale.

When a contrast is jarring rather than complementary, it weakens the centres involved. To protect the centres from discord, we can introduce a boundary that works well with both sides of the divide.

Some boundaries can be massive, almost as large as the thing they are bounding[NoO1-01]. They are not a thin line between things but can be thick like a moat or the margins of a book. They can be detailed, such as the dunes dividing a beach from the lands beyond or a brick wall surrounding the mouth of a well. They can be plain, such as the rim of a plate or the grounds around a building on a lawned campus.

They can be an absence, such as the solid material around the holes of a shower head. The boundary in the following image is not the thicker black line but the blank white gap between the outline and the detailed interior.

The value of boundaries can be how they extend the meaning of the separation while enhancing the visibility of the centre they surround. Boundaries can be around objects but also at the ends of linear things, such as columns or ropes.

The principle of boundaries is that they reinforce endings and divisions. In things that stop, they help recognise the termination and the preceding existence. Boundaries fulfil the need to say something about the differences between things while recognising the value in their presence.

Without boundaries, colours merge, and ends seem unfinished. Weak contrasts start to show as a failure to differentiate rather than an attempt to include.

Boundaries are places for details to be added without making space for them artificially. Fences or colonnades, patterns around a form, details in a design surrounding an emptiness; they all make good boundaries that reinforce and contrast.

I believe a boundary helps a contrast fit with its surroundings. If something is too dark, detailed, or colourful, a good boundary can provide the distance to smooth the transition. I have edited the image of the door on the right to show how it looks weaker and out of place when it lacks a border.

Christopher Alexander used an example of a Gothic door. I replicate the example here with a different image of a door and an alteration to remove the surround, showing the impact of not having the necessary framing.

Boundaries can be cell walls or rivers used as borders of countries. Boundaries protect a centre from the world outside. So, a line is not a boundary. Because without thickness, a boundary cannot protect.

So, although hairlines can indicate the location of a boundary, the true centre is the boundary extending to the white space above and below the line. The boundary is the whole form, the gap-line-gap sequence.

In books, some publishers aren’t aware of the importance of margins and push the text of a book out to the edges of the pages. Leaving a tiny gap for a border feels like a poorly framed centre on every page.

When I first learnt about typography and book layout, I did not understand why the inner margin can often be smaller than the outer, but now I see it as a way to emphasise the boundary around the two-page spread. The inner margin handles the fold and not much else. The outer margin is a companion to the top and bottom margin, not the inner. Boundaries are, therefore, contextual to where they are embedded.

Property 4 — Alternating Repetition

Alternating Repetition is introduced in The Nature of Order, Book 1[NoO1-01] on page 165.

Square grids are a typical result of splitting sequences from other splittings along a second dimension. They create rectangular grids that feel a little too flexible when realised.

Repetition is natural, and grids are common, but even more natural than these are where the grid has relaxed into something where the tiniest irregularities are de-stressed by being aligned to an off-beat. Consider the difference between a rectangular grid and a hexagonal grid. One is easy to work with, but the other is more satisfying to behold.

There are no triangles in square grids, so they are just waiting to fold up on themselves. However, the hexagon or triangular field is sturdy, or at least looks that way. Hexagons remind us of stacks of circles, which pack naturally into alternating layers. Triangles are triangles, and we immediately see them as sturdy.

Bricks are rectangles, so they look terribly fragile when laid out in a grid, but note how swiftly we change our mind when we layer them as per a wall with alternating placement. Even when a regular grid is pristine and well-engineered, it looks weak and unsettled compared to a roughly realised alternating form.

Scales on a fish[NoO1-01], the way the weave of fabric goes under and over, the teeth of a zipper, the in and out of jigsaw puzzle pieces, and the directions of alternating tiles in herringbone paving, are all examples of the same kind of strong pattern of interleaving by alternating repetition.

The alternation does not just need to be about structure but can also be about usage. We build small shops into our communities by interleaving commercial and residential. We plan out land with stopping and going as the alternation, with paths punctuated by points where things come together. We string focal points[APL77] such as monuments, ponds, and playgrounds together with paving, roads, and dirt tracks—an alternating pattern of movement and stillness in relatively similar quantities.

Property 5 — Positive Space

Positive Space is introduced in The Nature of Order, Book 1[NoO1-01] on page 173.

We must introduce positive space when we develop for a while and the foreground becomes much stronger than the backdrop. We don’t always need to weaken what we have done to remedy the situation. Positive space means to look at the gaps our work has created and see where they are awkward or need some support. You can think about positive space as relating to kerning. It does not matter how good the letterforms are without good spacing between characters. Poorly kerned text looks odd.

When something unfolds, it does so within some other medium or environment. The change introduced by its presence can help or harm. The concept of positive space suggests the best results are when the unfolding also considers the goodness of the negative space. So, the patch of ground left behind by the placement of buildings must be good as well. The shape of the empty air around an object should be as inviting as that displacing it.

We find examples of how this can be done well in the placement of buildings around a cosy village green or in a nicely designed shopping mall. The place to which people go when they are not shopping is as important as the shops to the feeling of it being a good place. In an image, we see it in how the object of the picture leaves a pleasingly shaped gap around it.

Some shapes seem like they should have good form (as we shall see in the following property) but have a tough time providing positive space. Circles are notorious for this[NoO1-01]; the lack of positive space is the reason organic shapes in buildings seem alien compared to squared-off corners and straight lines. Rounded shapes always leave a problematic concavity in the space they take up. Modern buildings with circular structures will have line-of-sight problems or unused space issues. Even the aforementioned circle-packing from alternating repetition sees this problem, as the spaces between circles have an extremely concave nature. To resolve this, we blow out the spaces in some way to make them better centres.

Circle packing is all about the circles. The gaps look like the leftover cardboard from punching out the tokens of a board game. They are waste. They are unusable. Without positive space, elements stick out, causing others to recede or weaken. The overall compound is reduced. The form as a whole is less effective for the sake of something that does not respect its neighbours.

This property is hard to comprehend, but my present interpretation of it is a wholesome and self-contained shape that is easy to consume. It is a way of saying that any element should be simple. Any complexity should present itself as a combination of things at a different scale, not as a convoluted shape or structure of a single piece. A form should be unified, consistent, and of one idea.

For example, the absurd-looking forms of sci-fi vehicles are not good shapes. Where the shape is not formed in response to the requirements of smaller pieces but instead whole cloth from the designer’s imagination, they are often inconsistent and complex. No construction takes place, so no lower-level order constrains the form.

Hand-drawn fantasy maps also have bad shape. They are generally unrealistic, as they have a forced shape from the author’s requirements. Their design doesn’t come from the natural laws of geography, so we can immediately tell they are fake through our instincts. Even the best random generators are detectable because the world has not been alive and there is no history to the location of the elements.

Christopher Alexander offers this list of qualities to help detect a good shape without having a feel for it:

1. High degree of internal symmetries.
2. Bilateral symmetry (almost always).
3. A well-marked center (not necessarily at the geometric middle).
4. The spaces it creates next to it are also positive (positive space).
5. It is very strongly distinct from what surrounds it.
6. It is relatively compact (i.e., not very different in overall outline from something between 1:1 and 1:2 — exceptions may go as high as 1:4, but almost never higher).
7. It has closure, a feeling of being closed and complete.

— Christopher Alexander, The Nature of Order, Book 1[NoO1-01], p. 183.

An example he points out is that of a circle¹. It would seem to be a good shape, but it fails in so many cases. Not because it’s a weak form in itself but because it creates unhealthy negative spaces around it, breaching point 4.

Good shape often goes unnoticed because the forms are not tense or distracting. We are more tuned to detect that which is uncomfortable, asymmetric, or poorly placed in its environment. Still, we have good forms with good shape around us much of the time.

Christopher Alexander found many examples of the properties in Turkish rugs. Good shape shows up as the elements but also in the shape of the groupings of them. Leaf motifs, frames, details, and branches all have good shape. But even in a good example, not all centres can maintain good shape without great care and attention. For example, look at the negative space around the detailed sections.

— Christopher Alexander, The Center for Environmental Structure, The Nature of Order, Book 1[NoO1-01], p. 182.

Many good shapes are interwoven in this rug

In all, good shape describes a quality of things that have unfolded well and have not made things worse for their neighbours. It might only occasionally be an ‘unfoldable’ property of its own, but it is a property that repeats in good things.

So, rather than use it as an unfolding to resolve a tension, use it as a guide. Detect newly arriving tension or detect when a centre needs to be split into levels of scale, a centre and boundary, or some other compound.

Property 7 — Local Symmetries

Local Symmetries is introduced in The Nature of Order, Book 1[NoO1-01] on page 186.

This property refers to not just symmetry but overlapping and interweaving symmetries. Snowflakes and other self-similar shapes have something like this, but local symmetries do not require a fractal nature. Instead, think only of the idea that the repetition is a repetition of something made up of something with repetitions.

Rather than start with something lacking symmetries, this property emerges from how unfolding processes operate. We don’t often repair a form back to having local symmetries, as they naturally arise from splitting, repeating, or using symmetry to reinforce structures.

A strong pattern is present there, but it’s not entirely self-similar. We needn’t be too strict about the facets either. This is cadence, poetic flow, and verse structure as much as mirroring or symmetry. Pleasant songs tend to have repetition at all different scales, and poems will have self-referential structural symmetry. Although a book of prose is unlikely to have much local symmetry, the left–right of the pages maintains at least a simple local continuity.

A terraced street will have symmetries[NoO1-01] in the row of houses. Even if each home has been made individual by its inhabitants, the alternating left–right door placement reinforces local symmetry. Other, smaller symmetries strengthen it further. The placement of windows and even the windowpanes and roof tiles deepen the character of the houses. It all adds up to a pleasing sequence along the whole street. The same is often true of any main market street with symmetric arrangements of roads, shops, frontages, and arcades with columns. Even the cobbles or paving slabs add to local symmetry. When you last walked along a solid and continuous poured concrete walkway, how did it feel compared to paving slabs or cobbles?

This property was proven in a series of abstract tests often referred to as the paper strip experiment. The 35 strips had all the possible permutations of three black squares on a strip seven squares long. Participants in the study were tasked with different tests to find an order to the strips according to how orderly, coherent, or simple they were. Though the test results differed, they were statistically similar.

Christopher Alexander collected the results and spent much time attempting to find the rationalisation for the order. Inspiration struck after some years when he considered local symmetries. He had been stuck on the idea of clumps and overall symmetry and had not considered how vital the sub-symmetries were. Calculating the score of the strips counting every symmetry, even those where the colours do not change, suddenly showed a very strong correlation to the ordering.

When biasing for longer, larger symmetric sequences, it seemed the correlation worsened. It proved to him that the number of symmetries was the most significant, not their size. The symmetries and sub-symmetries are the significant parts of the property.

The strip experiment and local symmetries in general can be considered to suggest the property is fundamentally about information density. Good forms are easily recognised. Ease of recognition comes from having patterns that match our preconceptions. Local symmetries give us something to latch onto. We can take one element of a scene and project it onto another as only a small piece of information—the duplication or mirroring of another element. We pattern match all the time, and the less pattern we can match the greater the cognitive load when trying to understand the whole—the more individual elements we have to concentrate on as we think about the compound form.

This parallels what we consider to be a natural unfolding. DNA works by a small number of rules, so there will be symmetries as every non-symmetric element is information and there’s only so much information in DNA. Our sense of what is good will be tuned to look for things with this quality of similarity of element.

When we see a lot of detail with many different ideas it either captivates through curiosity or repulses us with its vulgarity. Almost everything we consider beautiful is simple in this respect. Therefore, wholesome forms present otherwise complicated looking forms through repetition with any variation only present when it is of vital importance.

Property 8 — Deep Interlock and Ambiguity

Deep Interlock and Ambiguity is introduced in The Nature of Order, Book 1[NoO1-01] on page 195.

Interlock can be introduced when boundaries would be too isolating and lacking differentiation would muddle the centres into breaking with good shape. Where a transition between centres might be too ambiguous with a gradient, instead we can introduce an interlock of different unique elements.

The elements creating an interlock will share something in common. A porch or arcade[NoO1-01] is part of the outside world but also part of the building to which it is attached. A puzzle piece is connected to another by staking claim to that which is within the boundary of its neighbour but somehow also definitely its own. Other examples are more literal, such as the interlocking of joints in wood or foreground–background ambiguity.

Interlock makes it difficult to determine which element was adjusted to make the connection work. When we cut stone so it fits together, depending on what we remove and from which stone, it can be difficult to determine which was fit to the other. Ambiguity creates a pleasant, tangled sensation, a knot rather than a mess. In examples of interlocking where we lack ambiguity, the knotting is less pleasing. It feels more like one element takes centre stage.

A deep interlock respects the positive space of the thing giving way. We can see a negative example of this in the interlock of Inca (probably not actually Inca, but it’s referenced as such, so I will call it that here) stonework. The central stone (it’s famous, and known as the twelve-angled stone) dominates the shape of the stones beneath it, but it is cut for the benefit of the smaller stones above. They did not create a positive space for the larger stone, so they are interlocked, but not as pleasant as they could have been had they worked together to create a harmonious shape.

More harmonious interlock comes when there is a bi-directional commitment to the locking. The tiling lizards of M. C. Escher deeply interlock, so no lizard gives way to any other. They wholly interlock with each other. However, this interlock has little ambiguity.

Ambiguity is more like the kind where the background and foreground are uncertain, such as in an octagon and square tiling. The smaller squares could be the foreground or the background. However, this pattern is not strongly interlocking.

Many examples exist in the patterns of wallcoverings or textiles. Christopher Alexander’s collection of Turkish rugs, with their interlocking designs, had many excellent examples of this feature. You can spot deep interlock almost anywhere by staying alert for these overlapping centres.

An ambiguous interlocking form is one where the interlock is deep but not driven by one or the other aspect. As an example, an anchoring pattern where the anchors reach into the space of the other but also define the opposite shape, which is also the same. The interlock is clear, but which is locking the other is ambiguous. The same can be said of a three-circle knot.

When elements stand too far apart from their environment, not literally but as contrast without connecting, an interlock can help introduce them and make them part of the world. The covered paving outside a mall is both the outside and the mall and helps create an introduction, planting it better in its space. We can also actively avoid ambiguity and create a moment of hesitation. Notice how most service entrances open directly to the work environment and evoke a distinct split. The shock of the split reinforces how the public should not enter this way.

Property 9 — Contrast

Contrast is introduced in The Nature of Order, Book 1[NoO1-01] on page 200.

Centres can only really exist if they are differentiable. Wholesome objects are identifiable. An element is weakened without some boundary defining where it starts or ends.

If an element is not distinct from its neighbour, it will be seen as part of a larger whole, including that neighbour, weakening both and impacting the good shape. An element reduced this way recedes into a supporting role, becoming coupled and subordinate.

If this reduction is not wanted, if the cost of this diminution is too great, we have a force to resolve[NoO1-01]. If a boundary does not make sense, another option is available in the property of contrast. Contrast is a form of visible differentiation and enhances identity.

Contrast does not have to be colour but can also be texture, size, pattern, or anything we can sense. Borders must contrast with both the centre they bound and the surrounding space. I have a beautiful black bowl with a small detailed section at the rim. The detail contrasts with the plain matt body. The interior of the bowl has a glossy finish, contrasting to the matt exterior. Two different contrasts in the same object.

In The Nature of Order, Book 1[NoO1-01], on page 200, the prose lists some contrasts, including:

• light–dark
• empty–full
• solid–void
• busy–silent
• red–green and blue–yellow
• high–low
• soft–hard
• rough–smooth
• active–passive

Opposites are anything juxtaposing, such as thin wires or rods against a thick trunk of a structure, a matt surface against a mirror-like polish, and angular design against gentle curves. The specific aspect that is in opposition isn’t critical, but it’s imperative that the contrast differentiates the elements, helping to strengthen them using qualities taken to their extremes.

But not all contrasts are helpful. When a larger body sets a style or motif, incorporated elements must work hard to fit in when they break from the theme. Other times, the contrast is contrived; it becomes the central element, diminishing the truer centres[NoO1-01]. Consider how nothing stands out in films these days, as so many have an orange and teal colour grading. If everything is in contrast, nothing is.

So, although contrasts are a valuable tool in creating identity, you should not seek them out. Find ways to ensure they exist where needed, but not in their own right or without reason.

Property 10 — Gradients

Gradients is introduced in The Nature of Order, Book 1[NoO1-01] on page 205.

It’s not often we introduce a gradient directly, but instead we watch it emerge from how we transform the elements. However, you can plan for it if you’re aware of contradictory forces in your context. Rather than make a contrast, bring a gradient to make the transition smoother.

As forms grow in size and detail, some composition elements will seem different and gravitate toward each other while moving away from elements unlike them. In this way, a gradient will form. We see it in cultural groupings with those bridging divides, and how pebbles wash along a beach.

Other times, gradients appear when the whole is large enough to span such a distance that it interacts differently at each extreme of its presence. At one end, the set of values contrasts differently than at the other. The differing forces create tension across the whole centre, and this tension is resolved by creating subdivisions or introducing a gradient.

Steps and stairs, sizes and colours, and gradients of elements are typical of good forms. Sometimes, they are literal gradients, such as in a rising elevation. The elements across a garden form a gradient from the low, rough areas to a higher ground of beauty or elegance. The gradient needs only to be through a space. As you travel through it, some aspect must change.

Consider the gradient-like nature of 112 Entrance transition. Standing in front of a doorway, you are in a public space. As soon as you enter the porch, you are beginning to be inside. Beyond this short-lived gradient, there is another pattern interlocked with it. The hall is even more inviting, and the deeper you venture into the building, the more home-like it feels—an 127 Intimacy gradient. Neither gradient is a sliding scale or gradual slope, but a feeling that grows or shrinks depending on how far removed you are from the outside world.

In organisations with security concerns, you might also encounter the secrecy gradient—a confidence gradient. The further into a building you get, the more locked down it is, and the more sensitive information will be present. Going from the front desk to a manager’s office to their filing cabinet requires progressively deeper acknowledgement of permission and authority.

Gradients can also affect the density of designs. Sometimes, the detail increases because the end requires some differentiation to achieve its goals. Tools often have detailed work ends or handles for this reason, and bones have the same increase in detail at their ends. However, the concentration of detail need not be discrete like in levels of scale. It can slowly change across a dimension, such as the spots and stripes on animals.

Most modern methods find realising good gradients quite demanding. Modular design works best when there are no gradual changes, so natural feeling gradients become expensive and regressive against any value this approach provides. We should not devalue gradients; instead, we should point out how modularity inhibits this property from ever appearing.

Property 11 — Roughness

Roughness is introduced in The Nature of Order, Book 1[NoO1-01] on page 210.

Natural things will look better when they are not too pristine and perfect. Not out of some hearkening to a time long gone, but because perfection creates a difficult time for the adaptation required for the best possible fit.

When your repetitions are precise, or your lines are no thicker than a hair, you open yourself up to cascading failure and complexity of interaction. A 5mm movement in one piece will require every other part to make space for the change. We want to reduce complexity and keep things simple. So, to allow local changes to happen without disturbing others, we introduce and expect an amount of roughness, so we can work around any imperfections we encounter.

In The Nature of Order, Alexander states that this makes them ‘more precise, not less so’ which I interpret as the opportunity to adapt granting the forms better capacity to properly reinforce their neighbours and not be disturbed by their irregularity.

If a grid is made of fragile modular pieces that cannot withstand bending or cutting, then the overall structure will be only as flexible as those modules. When you see a large or long tent at an outdoor event, it follows the contour of the grounds or uses ropes that take up any slack. Look at a brick wall on a rising street and see how the bricks help because they are cuttable.

If you can’t bend things a little, the final form will seem awkward or impinge on its surroundings. Roughness makes the slight movement and variations normal. When you expect deviation, adjustment is natural and fitting. Then, you get the deeply interlocked, tight, snug but relaxed final forms.

Without roughness, a shared edge feels off. Without roughness, a picture feels unreal. Even a brick wall, with perfectly laid bricks, still has a roughness of the brick surfaces. You may have been in a building with wall coverings imitating bricks and noticed they didn’t look right. A linoleum floor which emulates tiles can look tacky when they are all too perfectly placed. These perfect versions are not better. They are inhuman. They suck the feeling out of the space.

Note that the perfectly interlocking blocks of the Inca stonework walls mentioned in the deep interlock section do not have a feeling of genuine roughness. They are too perfectly placed. They took too much effort. The dry stone walls of an English countryside might be too loose, but something in the middle is the goal.

Property 12 — Echoes

Echoes is introduced in The Nature of Order, Book 1[NoO1-01] on page 218.

Echoes, or self-similarity, are similar to design motifs. There can be a recognisable element occurring at different scales and under different guises. It could be a colour combination, a set of angles, or how things are connected. When we echo the details this way, it makes the whole a cohesive thing, even if it goes on and on.

Rather than actively introduce echoes, we instead attempt to maintain some self-similarity as we accept new elements into the design. We reject ideas that add unnecessary variation and invite others which mirror aspects of the elements already present.

When a project grows, more people work concurrently on its development. Having more minds invites more ways of solving problems. But if we restrain ourselves and maintain the vision, we produce work with echoes throughout. When a design starts to veer off, we see more themes or fonts than are necessary. A level of variation is typical of something living but those variations will be thematic because natural processes usually pull from a palette of options.

We can see how it hurts in collections with limp central themes which need more definition. Some buildings try to conform simultaneously to multiple styles and exhibit a loss of identity. Art that attempts to represent more than one aspect can lose itself to meaninglessness[NoO1-01]. The same statement can be applied to a presentation or document that doesn’t make a cohesive argument. I hope this last point isn’t relevant to this book.

Sometimes, all you need to do to create echoes is use the same materials. Materials tend to guide their use and often suggest themes by their limits. So do the restrained usage of fonts in your document or a narrow palette of colours on your website. When you have a lot of different styles, they break the echo. You must tame the styles by grouping them or separate them into contrasting collections rather than a soup of randomness.

Any architecture lacking echoes almost implies it has too much complexity to remain stable. Echoes of forms help create repeatable patterns of stresses and strain, which allows the builder to judge the limits of the material better, as there is less to consider. Without echoes, there are too many variables. Notably, echoes are often absent in software architecture, as DRY causes echoes to look suspicious.

Echoes are used to repeat elements over different levels of the hierarchy of life. We have giant malls, superstores, mini-markets, and corner shops. These are like coarser-grained levels of scale of the same resource. They cater for the differing scales of different types of consumers. From national parks to regional parks to local parks to local common green spaces, the scale of space and use is graduated but echoing. Each is a scale up or down to the next and helps address the needs of a different user, as the users echo across different ages and group sizes. But notice that the scale is not too close. The small park feels unnatural next to another, similar-sized park. A small shop can be more competition for another small shop than a mall is, as a mall brings a different type of consumer.

Property 13 — The Void

The Void is introduced in The Nature of Order, Book 1[NoO1-01] on page 222.

Sometimes, a significant non-presence is what is lacking. Too much of anything is, again, nothing. One way to think of the void is to create a sense of scale and relevance through the presence of an absence. If your design is devoid of high-level focal points, perhaps it is because there is nothing simpler and larger for them to have value in relation to.

You can find the void in buildings and images, but also in the dynamics of a concert where there is a silent section. It presents itself in a film as a lull leading into action. The void is an active lack placed in a prominent location, bringing about a contrast of information—the part that sets the negative example.

In buildings and artwork, it can be a literal space in the design: a great hall, an emptiness on the canvas. The void can be a way to suggest a place to stand to perceive everything else. The void helps in the way the air in a bubble is fundamental to the skin.

The void also forms a contrast, suggesting what would happen if the rest of the compound was absent. It can make elaborate designs seem more intricate without introducing noise. The void can be a focus. It has a sense of solemnity compared to its surroundings and provides a way to suggest maturity, freedom, or a reflection of the self. What you notice when looking at plans of buildings where there is a void compared to those without is that those with a void have immediate character. They seem like there can be a purposeful assembly. It could be as mundane as the central courtyard of a farm. The large open area between the home and the many outbuildings. The yard is a place welcoming a crowd, but also a gap over which your mode of being can switch from work to home.

Christopher Alexander uses[NoO1-01] a typical 1970s American office building as an example of where the void is missing. They almost never have anything like this. Rather than allocate space for a large hall, they have many smaller meeting rooms. The latent void is often filled with desks, divided by stubby walls upon which yellow notes carry essential information such as passwords. As effective as the void is, it is inefficient and so is removed from all possible suggested floor plans.

But the void need not be empty to be a void. It is simply a calm space—a realm of neutrality amid the intentional design. In a computer game with a vast world, between the noise and information-dense cities or markets, there is often a land of walkable terrain. This terrain can act as a void, even when it contains much wildlife. In this sense, the void amplifies the noise in the game hubs by contrast of opportunity.

I do not see the value of the void in code, but the main loop or the central dispatch might be the hub around which all valuable transformations take place. They provide some of the value of the void. They are something of a focus, but also somewhere to which value is contributed from outside. A main loop does nothing by itself. Neither does a message bus. They are the busy nothing at the centre.

Property 14 — Simplicity and Inner Calm

Simplicity and Inner Calm is introduced in The Nature of Order, Book 1[NoO1-01] on page 226.

Some forms cannot be calm or simple. What they are about is their complexity. Examples include patterned wall coverings or other decorative elements. However, some things must gain this property as they grow in size. They must simplify, attain an essence of eternity, and begin to emanate a sense of stasis. Not stuck or dead, but steadfast, unshakeable, and waiting. Noisy things do not seem to have this. Simplicity comes first, then calm.

When a large object, or at least one that dominates a space, has too much character, we want to slow it down and mute its harshness. As beautiful as they are, many Western buildings constructed as a form of praise do not have this property. They have too many parts that seem like they are still in motion. The buttresses are flying, and the friezes are not frozen. The details mean there is nothing on which you can rest your eyes and defocus.

The good examples in architecture are abound with columns and massive stone structures but also with things that are not so much large as they are simple and not heavily ornamented. The inclusion of fewer details magnifies the apparent size of these simple things. We find the opposite in buildings with haste in their lines. They may be adorned with facets that work well but never catch a breath. They are, therefore, not calm.

This calmness can be the difference between word processors and distraction-free writing applications.

In The Nature of Order, Book 1[NoO1-01](page 227), Christopher Alexander’s suggestions for Shaker furniture (which I paraphrase here) are:

• It uses very simple shapes.
• The ornament is very sparse, but is occasionally present …
• The proportions are unusual. Elongated, high, long, tall, broad, etc, but for practical reasons such as to use all the available space.
• Strange in some specific way, such as unexpected openings or additions. In effect, emphasising an extreme freedom to do what needed to be done.
• Coloured in a deep way. Right into the wood. Not painted.
• Finally, everything is still, silent.

These properties generate inner calm in Shaker furniture. We can think of some of these points as not responding to judgement, not caring about appearance but being its authentic self. The mood is all about having a duty and performing it in the best possible way despite tradition or other expectations. This inner calm is a respect for itself and confidence to exist.

For negative examples, consider the inclusion of a parapet on a modern building. It’s an old form, but it is not in keeping with the theme. It marks itself as quirky and actively different. This is the difference between an eccentric who wears their dressing gown when going out in public simply because it’s comfortable and the ‘look how random I am’ teenager who wears odd shoes as a form of self-expression.

So, inner calm does not exist in wacky objects, whether in architecture, furniture, art, or rugs. Elements that break from tradition for the sake of breaking are not calm. They are tense, waiting to see a reaction. They become dependent on the observer and are weakened by this neediness because they are for something other than their own completeness.

Extending a creation can interrupt the space. The themes can clash rather than contrast. The boundaries can alienate rather than define. When this is the case, we need to resolve the differences back to what they should have been already: adaptations to repair a problem.

The whole thing should be cohesive, not just within itself but also within the environment of which it is a part. It was already mentioned in the section on good shape and positive space how the outside matters. Not-separateness extends to how the thing should be present in the space by complementing it, even healing it of something that currently stresses it.

It means not to stand out[NoO1-01] but to be at home. When thinking about not-separateness, we should regard the outer compound of that which we’re observing because it includes the environment. It would stress the levels of scale to have one element stand out compared to hundreds of others nearby.

Christopher Alexander found it lacking in some buildings. They seemed to shout, ‘Look at me!’¹ which harks to an ego-driven creation—a creation that wants to stand out because its value is in its peculiarity or distinctiveness. Perhaps it is trying to say something about the creator. These separated things stem from a sense of self-absorption.

But being obvious is not always separate. Consider grand cliffs, which almost cry out how awe-inspiring they are. But they are very much part of the land. A lighthouse on a peninsula is bright and radiates out for all to see—but not for its sake. A church stands out proudly as a beacon for the faithful, but it welcomes and includes the parish with grounds oriented to create a boundary that smooths any transition.

Not-separateness is a pervasive property for all elements because it requires everything to be somewhat connected; otherwise, it is disconnected. And disconnects are rifts we need to heal.

— Christopher Alexander, The Center for Environmental Structure, The Nature of Order, Book 1[NoO1-01], p. 238.

For example, without strong centres, there can be no reference to the good shape of those centres. Local symmetries make little sense when you cannot differentiate, so depends on contrast. What is local about the symmetries is often defined by where it stands in levels of scale or relation to the void. Gradients imply a form can flow over a field connecting to not-separateness but also contrast. Boundaries and levels of scale imply centres and thus rely on strong ones to help define them. Contrast requires separation, so often implies boundaries or characterises the transformation of a gradient to a more explicit transition.

This interaction between the properties would be a weakness if they were building blocks of construction, but they are not. They are the properties of forms produced by taking natural steps of growth. They can be differentiating, extending, relaxing, defining, or refining. But they are never a mindless accretion of novelty or the result of top-down outside-in thinking.

These are all properties discernible when the growth process is a sequence of unfoldings punctuated with moments of relaxation. In effect, fully complete steps, including the moment to let things settle long enough to pick up on subtle hints to the best next direction.

Christopher Alexander connected the properties to natural processes[NoO1-01]. Gradients form as the ends of an element relax and regress to the mean of their surroundings. Levels of scale form as parts split, with some resultant sub-elements growing slower than others as things progress. Alternating repetition forms around weak sequences that collapse and pack into robust structural patterns through annealing or sliding into place. Roughness is recognising the negative, that purity and regularity often indicate a stress on surrounding forms. Boundaries appear by connective structure rather than allow for weak edges. Deep interlocks form when boundaries or contrasts fail to satisfy forces completely.

In effect, Alexander pointed out that all the properties are what we should expect when we grow a solution by the mechanisms natural to the physical world and when we allow it to form through a sequence of steps inspired by local revelation.

Can we use the properties to guide us when creating the sequence of actions we take? We can ask what is not quite right about the properties of our current forms. We can ask what feels stretched or underrepresented in the current configuration. What appears to be missing can always guide us to a healthier form.

But we can only do this if we have the properties for our domain. These properties are unknown with code and, like with prose, possibly absent. However, the payoff for discovering them could be huge.

The properties of colour and beyond

Christopher Alexander did not stop at the fundamental properties of forms but also tried to find fundamental properties in other aspects of design. He studied colour to a great extent and surfaced 11 properties. Try as he might, Christopher Alexander claimed he could not find a way to map the properties of colour to the existing 15 properties of forms directly[NoO4-04]. Instead, he did so with some overlaps.

There are fewer properties of colours than there are of forms, but they cover a very similar set of attributes. Colours are used in various ways, from images to photo composition to wallcoverings to the exterior colouring of houses, cars, and sites. Whatever the usage of colour, it is seen. A web page uses colour, and so does a painting in a gallery. They may not be in the same league, but perhaps that merely depends on the painting and the site. In each case, the spectator of the colour views a scene in which the colour has its chance to shine. So, rather than talk about buildings, paintings, rugs, or objects, I will refer to the entire set of observable ‘colourables’ as scenes.

First, I will attempt to describe a few of the properties as I did for the 15 properties of form. I won’t do that for all the properties of colour, as you don’t need to know all of them to understand how they are similar and how they differ.

Hierarchy of Colours

Hierarchy of Colours is introduced in The Nature of Order, Book 4[NoO4-04] on page 174.

As with levels of scale, a scene has proportions of colour. With levels of scale, identifying the proper proportions relies on the repeated or contrasting parts. With colour, each pigment’s hue, saturation and brightness will affect how much of the image it should cover. The hierarchy of colours is numerical, based on the area of the image that is covered by each colour[NoO4-04]. Invariably, a good ratio is not an equal ratio. Symmetry is never relaxed with colour.

I also note how a heavy colour will appear to take up more space even if it consumes slightly less. To balance a scene, a weighty colour must either dominate or recede. ‘Heavy’ does not refer to dark but always means an imposing colour. I suggest a brilliant green is a heavier colour than a pale pink. I also note that colour weight is very often evaluated relative to the other colours in a scene, so a strong blue in one scene recedes in another by lack of contrast.

The ratios, like with levels of scale, are found by observation and adjusted into place. They are often proportional, in the realms of 2:1 to 5:1, but also include sub-sequences of ratios. A good combination of red, blue, and yellow might be 7:4:1, with the yellow so intensely brilliant, it must be tamed and surrounded by the closer weighted blue and red[NoO4-04]. But colours can work even when they are at more extreme ratios than the physical, as the presence of a minimal quantity of a vibrant colour can impact the entire image by contrast. So, you can often see good combinations where the ratio is as high as 20:1. But images muddied by too many colours have no intense primary. Some colour needs to be the dominant one. In the remaining space, another colour needs to dominate that too.

But dominating the other colours usually leads to having less meaning. Typically, the rarer colours control the message of the scene. The small amount of black or yellow in a light or dark background will dominate the structure, if not its overall hue. This juxtaposition, which defines the visible structure, leads to the next property.

Colours Create Light Together

Colours Create Light Together is introduced in The Nature of Order, Book 4[NoO4-04] on page 179.

A colour on its own says little. For it to have meaning or convey a sense of softness, harshness, warmth, or serenity, it must be brought together with another colour. The obvious case we can think of is the orange and teal colour grading in many modern films. The need to make flesh tones pop led to many movies being recorded and colour-graded to a uniform blue–orange wash. These complementary colours work well to increase the vibrance in each other, even when we have already seen a hundred overly graded productions. They are fundamental colour theory contrasts of hue. But creating light does not have to be about contrast; just what makes an impact by relation. Some colours are raised in their value for a scene by a nearby colour acting to reinforce how deliberate or nuanced the choice was. The difference between red and gold is not so huge, but so much artwork with red–gold colour exists because the red reinforces how pure the gold is, and the gold reminds us of how warm red is when next to an orange or yellow colour.

Christopher Alexander puts this property against positive space[NoO4-04], seemingly because a colour creates a field in which another colour ‘shines’. But he also connects it to alternating repetition. This link reminds us that contrast is the element, not the colours that complement each other. It’s the enrichment that has been brought about.

It’s worth noting that colours support each other, even when they are nearby neighbours, as long as their proportions are right and they have some other way to cast light on each other. This leads to the next property.

Contrast of Dark and Light

Contrast of Dark and Light is introduced in The Nature of Order, Book 4[NoO4-04] on page 186.

Two colours that generally work well together can muddy themselves by not taking care of light and dark[NoO4-04]. There’s hue and saturation in colours, but there’s also brightness. Each primary colour has a natural level of lightness. Green is the brightest, then red, then blue. If you intended to create a nice contrast with red and green but brought the green down to a darker shade, the complement would be weaker. Some artists would call this working with values, not colour. The concept is simply that an image should work as well in black and white as when colour is perceived.

What this means for us

Rather than go into detail on all the remaining properties, you have an idea of the contents of each of them, and you can begin to see how these connect to the fundamental properties of form. The properties of colour are similar, but even when they are very similar, some differences stand out. This makes sense, as how we evaluate these properties has so much to do with what looks natural, and what looks natural is that which naturally occurs.

I believe, in domains of perception by humans, there will be other sets of fundamental properties. Immediately, we may assume there are properties for music, food, art, dance, poetry, and prose. I would not want anyone to presume these lists are final, but I present them here as examples of what we might find if we were to look for properties in other domains.

  def GetAuthors(self):
    return self.author

  def GetTitle(self):
    return self.title

  def GetPublicationDate(self):
    return self.date

  def GetNotes(self, book):
    if isinstance(book, Book):  # if a book, turn into book_id
      book = book.reference_id
    return [note
        for note in self.notes
        if note.reference_id == book]

  def GetBookList(self):
    return self.books

  def GetBooksByAuthor(self, author_name):
    return [book for book in self.books
            if author_name in book.GetAuthors()]

  def GetBooksInDateRange(self, start_date, end_date):
    return [book for book in self.books
            if start_date <= book.GetPublicationDate() <= end_date]

  def GetBooksMatchingTitle(self, match):
    return [book for book in self.books
            if match in book.GetTitle()]

  def GetBooksMatchingSubjectWithNotes(self, match):
    return [book for book in self.books
            if match.lower() in book.GetTitle().lower()
            and len(self.GetNotes(book))]

  def GetBooksByAuthorInDateRange(self, author_name, start_date, end_date):
    return [book for book in self.books
            if author_name in book.GetAuthors()
            and start_date < book.GetPublicationDate() < end_date]

  def GetBooksMatchingSubjectButNotByAuthor(self, subject, author_name):
    return [book for book in self.books
            if author_name not in book.GetAuthors()
            and subject.lower() in book.GetTitle().lower()]

  def GetBooksInDecadeSortedByRef(self, decade_start):
    return sorted([book for book in self.books
                   if decade_start <= book.GetPublicationDate()
                   and book.GetPublicationDate() < decade_start + 10],
                  key=lambda x: x.reference_id)

  library = Library()
  print("Books with notes, on the subject of programming")
  print_books(library, 
              library.GetBooksMatchingSubjectWithNotes(
                  "program"))
  print("Books by Takashi Iba")
  print_books(library, library.GetBooksByAuthor("Takashi Iba"))
  print("Early books by Christopher Alexander")
  print_books(library, library.GetBooksByAuthorInDateRange(
      "Christopher Alexander", 0, 2000))
  print("Books by others on architecture")
  print_books(library, library.GetBooksMatchingSubjectButNotByAuthor(
      "architecture", "Christopher Alexander"))
  print("Books from the 80s, sorted by RefID")
  print_books(library, library.GetBooksInDecadeSortedByRef(1980))

def GetBooksMatchingSubjectWithNotes(selflibrary, match):
  return [book for book in selflibrary.booksGetBookList()
      if match.lower() in book.GetTitle().lower()
      and len(selflibrary.GetNotes(book))]
 
def GetBooksByAuthorInDateRange(selflibrary, author_name, start_date, end_date):
  return [book for book in selflibrary.booksGetBookList()
      if author_name in book.GetAuthors()
      and start_date < book.GetPublicationDate() < end_date]
 
def GetBooksMatchingSubjectButNotByAuthor(selflibrary, subject, author_name):
  return [book for book in selflibrary.booksGetBookList()
      if author_name not in book.GetAuthors()
      and subject.lower() in book.GetTitle().lower()]
 
def GetBooksInDecadeSortedByRef(selflibrary, decade_start):
    return sorted([book for book in selflibrary.booksGetBookList()
                   if decade_start <= book.GetPublicationDate()
                   and book.GetPublicationDate() < decade_start + 10],
                  key=lambda x: x.reference_id)

  library = Library()
  print("Books with notes, on the subject of programming")
  print_books(library,
              library.GetBooksMatchingSubjectWithNotes(
                  library, "program"))
  print("Books by others on architecture")
  print_books(library, library.GetBooksMatchingSubjectButNotByAuthor(
      library, "architecture", "Christopher Alexander"))
  print("Books from the 80s, sorted by RefID")
  print_books(library, library.
              GetBooksInDecadeSortedByRef(
                  library,
                  1980))

def GetBooksMatchingSubjectWithNotes(library, notes, match):
  return [book for book in library.GetBookList()
      if match.lower() in book.GetTitle().lower()
      and len(librarynotes.GetNotes(book))]

  library = Library()
  notes = Notes()
  print("Books with notes, on the subject of programming")
  print_books(librarynotes,
              GetBooksMatchingSubjectWithNotes(
                  library, notes, "program"))
  print("Books by others on architecture")
  print_books(librarynotes, GetBooksMatchingSubjectButNotByAuthor(
      library, "architecture", "Christopher Alexander"))
  print("Books from the 80s, sorted by RefID")
  print_books(librarynotes, GetBooksInDecadeSortedByRef(library, 1980))

def WithNotes(books, notes):
  return filter(lambda book: len(notes.GetNotes(book)), books)

def ByAuthor(books, author_name):
  return filter(lambda book: author_name in book.GetAuthors(), books)

def InDateRange(books, start_date, end_date):
  return filter(lambda book: start_date <= book.GetPublicationDate() <= end_date, books)

def NotByAuthor(books, author_name):
  return filter(lambda book: author_name not in book.GetAuthors(), books)

def MatchingSubject(books, match_string):
  return filter(lambda book: match_string.lower() in book.GetTitle().lower(), books)

def SortedByRef(books):
  return sorted(books, key=lambda book: book.reference_id)

def InDecade(books, decade_start):
  return InDateRange(books, decade_start, decade_start+10)

  library = Library()
  notes = Notes()
  print("Books with notes, on the subject of programming")
  print_books(notes,
              GetBooksWithNotes(MatchingSubjectWithNotes(
                  library.GetBookList(), notes, 
                  "program"),
                        notes))
  print("Books by others on architecture")
  print_books(notes, GetBooksMatchingSubjectBut(NotByAuthor(
      library, "architecture".GetBookList(), "Christopher Alexander"), "architecture"))
  print("Books from the 80s, sorted by RefID")
  print_books(notes, GetBooksInDecadeSortedByRef(InDecade(library.GetBookList(), 1980)))

def WithNotes(books, notes):
  return filter(lambda book: len(notes.GetNotes(book)), books)
 
def ByAuthor(books, author_name):
  return filter(lambda book: author_name in book.GetAuthors(), books)
 
def InDateRange(books, start_date, end_date):
  return filter(lambda book: start_date <= book.GetPublicationDate() <= end_date, books)
 
def NotByAuthor(books, author_name):
  return filter(lambda book: author_name not in book.GetAuthors(), books)
 
def MatchingSubject(books, match_string):
  return filter(lambda book: match_string.lower() in book.GetTitle().lower(), books)
 
def SortedByRef(books):
  return sorted(books, key=lambda book: book.reference_id)
 
def InDecade(books, decade_start):
  return InDateRange(books, decade_start, decade_start+10)
 
def And(a, b):
  return lambda book: a(book) and b(book)
 
def Not(a):
  return lambda book: not a(book)

  library = Library()
  notes = Notes()
  print("Books with notes, on the subject of programming")
  print_books(notes,
              filter(
                  And(WithNotes(notes),
                      MatchingSubject("program")),
                  library.GetBookList(),
                  "program"),
                        notes))
  print("Books by others on architecture")
  print_books(notes, filter(
    And(MatchingSubject("architecture"),
      Not(ByAuthor("Christopher Alexander"))),
    library.GetBookList(), "Christopher Alexander"), "architecture"))
  print("Books from the 80s, sorted by RefID")
  print_books(notes, SortedByRef(
      filter(InDecade(1980), library.GetBookList(), 1980)))

  def GetBooks(self, spec):
    return filter(spec, self.books)

  library = Library()
  notes = Notes()
  print("Books with notes, on the subject of programming")
  print_books(notes,
              filterlibrary.GetBooks(
                  And(WithNotes(notes),
                      MatchingSubject("program")),
                  library.GetBookList()))
  print("Books by others on architecture")
  print_books(notes, filterlibrary.GetBooks(
    And(MatchingSubject("architecture"),
      Not(ByAuthor("Christopher Alexander"))),
    library.GetBookList()))
  print("Books from the 80s, sorted by RefID")
  print_books(notes, SortedByRef(
      filterlibrary.GetBooks(InDecade(1980), library.GetBookList())))

def ShorterThan(dimensions, upper_limit):
    return lambda x: dimensions.get(x.GetTitle()).Height() < upper_limit

def SortedByAuthorLastName(books):
    return sorted(books, key=lambda x: x.GetAuthor()[0].split(" ")[-1])

meal_dict = {
    "Starter": PrawnCocktail,
    "Main": Risotto,
    "Dessert":CheeseCake,
    }

def MealTime(meal_dict):
    PlaceCutlery()
    meal["Starter"]()
    Cleanup()
    meal["Main"]()
    Cleanup()
    meal["Dessert"]()
    Cleanup()

def recurse_apply(node, operation):
    if isinstance(node, Node):
        for child in node.children:
            recurse_apply(child, operation)
    else:
        operation(node)