Introduction

This wiki documents a pattern language, the language used by the Gaiwan team.

The concept of a Pattern Language was proposed by Christopher Alexander, an architect and design theorist active in the second half of the 20th century, in a sequence of three books. This influenced a design patterns movement within Software Development, kick-started by the book Design Patterns: Elements of Reusable Object-Oriented Software (1994).

This book has had an outsized impact on Software Development practice and discourse, and has shaped the general understanding of what design patterns are and how they apply to developing, deploying, and maintaining software.

What is a Pattern?

If you have been around in software for a while, you likely have a number of preconceived notion of what a "design pattern" does or doesn't looks like. For this wiki we take a broad look, inspired by Alexander formulation of pattern forming a language.

Here are some common conceptions we don't subscribe to:

  • Design patterns are mainly about objects and classes (not true, at any level of system design and development, and in any flavor programming, patterns occur)
  • "Design pattern" refers specifically to one of the patterns in the book (not true, many more patterns have been described, and many more exist but have not formally been described)
  • Only in specific cases do you use a design pattern, the rest is just "regular code" (not true, if you look closely you will find patterns implicitly in almost all the code you write or systems you build, fractally)
  • Patterns have a typical size, somewhere between a few and a few dozen objects (not true, patterns are in fact fractal, meaning most patterns form a combination of smaller patterns, and are themselves components in bigger patterns)
  • Once a pattern has been formally described it is set in stone, and unless an implementation follows the description to the letter, it can not be seen as an implementation of said pattern (Patterns form a language, and language evolves to adapt to a changing world)
  • A pattern description has to follow the formal template used in the Design Pattern book (It's good to have a template and common organization, but we don't want that to hold us back from describing and publishing patterns we see.)

A Pattern Language

In terms of the source material, the most commonly referenced of Alexander's books is A Pattern Language (1977), which describes a specific set of patterns which Alexander and his collaborators found to be a useful and sufficient language for building. However, to truly understand the intent and scope of design patterns we have to read The Timeless Way of Building (1979), which was published a few years later, but which Alexander saw as the predecessor of A Pattern Language, setting the stage and explaining his philosophy and intent. This is the source material that we go back to for our conceptualization of A Pattern Language.

It is important to note that a Pattern Language is a language, an idiom, which shares many characteristics with natural language.

  • It is shared by a group of people, which use it daily as a means of communication, and as a basis for developing and expressing ideas
  • Different but adjacent groups will often speak similar (overlapping) but distinct languages
  • Each person uses the language slightly differently
  • Language evolves over time, it grows and changes, meanings evolve
  • A word's meaning is its usage (this is descriptivist rather than prescriptivist view of language, which we subscribe to)

Much like natural languages, a pattern language may evolve over time as it grows and changes and meanings shift. A word's meaning is its usage (this is descriptivist, rather than prescriptivist, view of language with which we agree), and so too with a pattern: how it is used determines what it means beyond any prescribed definition.

The pattern language described in the Tea Garden is the language spoken by the Gaiwan team, our common vernacular. The patterns in our pattern language can extend from the very small (tiny programming language idioms) to the very large (deployment and maintenance of entire systems), and even beyond the purely technical to organizational and social patterns. We describe patterns wherever we see them and find them useful and hope that, by sharing them here, others can benefit from the growth and evolution of our pattern language.

Conclusion

For Alexander, a Pattern describes a set of relationships between building or environmental elements that, when followed, help to resolve tensions and inner contradictions that exist within the larger system. This is a very useful framing. Much of the software pattern literature talks about "forces" rather than "tensions". We prefer "tension", since this is also what one feels while working on these systems. Trying to combine elements in software design is not always straightforward. The software pushes back. It creates tension, and we as developers and architects feel that tension within us. A good pattern will allow us to resolve these tensions, and when we reach that point we will literally experience a feeling of resolution and release.

By applying these patterns, and resolving these tensions, we can hope to approach a Timeless Way of Building Software. Software that is imbued with the quality without a name. Alive, whole, elegant, precise, ego-less, eternal, free from inner contradictions.