A pattern is an element of design that is most commonly ascribed to the architect Christopher Alexander, who uses a pattern-based approach to the construction of towns, neighborhoods and buildings ([BibRef-Alexander1977], [BibRef-Alexander1979]). Each pattern solves a problem by adding structure to a system. The main tenets of the pattern approach to system construction include incremental repair and piecemeal growth, building on experience, and an attentiveness to quality of life. Alexander's ideas were adopted by the software community, and in particular by the object-oriented programming community, in the early 1990s.
The concept of pattern is difficult; it is plagued by more misunderstanding than were ever suffered even by terms like "object" and "function" of the 1970's and 1980's. There are aspects of the definition that are intuitive--"a solution to a problem in a context"--yet a pattern is much more than that. In this book, your intuition about what the term "patterns" means will take you far as you build and repair your organization. But a deeper knowledge of patterns will make it easier for you to extend the pattern language with your own patterns, and to experience the joy that comes with the freedom of playful and insightful organizational design.
To fully understand what a pattern is, you must first understand what a pattern language is. A pattern doesn't exist apart from a pattern language; its first purpose is to establish connections to other patterns in the language ([BibRef-Alexander1977], p. xii). But to understand pattern languages, you must first understand what a pattern is. We know this is recursive, and to understand recursion, you must first understand recursion. We must start somewhere, and we start here: with patterns.
Here is a short and necessarily incomplete definition of a pattern:
A recurring structural configuration that solves a problem in a context, contributing to the wholeness of some whole, or system, that reflects some aesthetic or cultural value.
Some of these aspects of pattern don't come out in the popular literature, and you may not find them all in the same place in Alexander's definitions. But they are the key elements of what makes a pattern a pattern, and what makes it different from a simple rule. A pattern is a rule: the word configuration should be read as "a rule to configure." But it is more than just a rule; it is a special kind of rule that contributes to the overall structure of a system, that works together with other patterns to create emergent structure and behavior.
Let's jump into an example. Consider the pattern TeamPerTask. Let's discuss each section of the pattern in turn interleaved with explanatory commentary.
That's the name of the pattern. We try to make pattern names descriptive, and sometimes even evocative. The name is a shorthand by which we'll refer to the structure, forces, solution, and so forth of the pattern as a whole, and it's important that patterns have good names to support good communication between you and your colleagues as you evolve your organization. The two stars after the name are a confidence level for the pattern; there can be zero, one, or two stars depending on how often we have seen the pattern applied and depending on our sense of confidence about the pattern's value.
... a big diversion hits the team, threatening to disrupt the ongoing work, and temporarily halt progress.
This is the context in which we find the problem. The context tells us something about the current structure of the system and may give us a hint about what other patterns already have been applied. After this prologue is the following delimiter, which leads into a discussion of the forces, or trade-offs, behind the pattern:
★ ★ ★
Large distractions (usually called crises) must not be allowed to stop a project, even for a short time. Crises are inevitable, and they are legion. If the project takes time to respond to each, its members will soon find themselves spending so much time responding to each crisis that the real work doesn't get done.
Of course the diversions are real. A previous release needs an emergency bug fix. New people must be trained. The ISO audit will happen. But they must be handled in a way that the project still moves forward.
At this point we have a sense that this is a tough problem! These "forces" draw out the considerations that must be balanced in the solution. They point to the nub of the problem and, in summary, are a statement of the problem itself. In this pattern form--called Alexandrian form, after Christopher Alexander--there is no real separate problem statement. We can interpret the emboldened part of the forces to summarize the problem, but it is all the forces together that cause the problem.
The problem isn't context-free; it is not a law of nature, but arises in a cultural context. Each culture has its own aesthetics about what is acceptable and what is gauche, what is constructive and what is unacceptable. Patterns honor this human element of design.
Next, we present the solution after a ceremonious "Therefore":
Therefore:
Let a sub-team handle the diversion, which allows the main team to keep working.
One approach is to split the team. Sort the activities so that each team has a primary task with additional, sympathetic activities. Sitting in meetings, answering phone calls, writing reports, for example, are non-sympathetic to designing software. Arrange it so that each team can focus on its primary task, and each task has a dedicated team member.
★ ★ ★
We close off the solution with another set of stars, and then go into some discussion about why the pattern works: how it balances the forces, what the strengths and liabilities of the pattern might be, and so on:
The result is that the important distractions are handled pretty much entirely by specialized teams, thus allowing the main team to continue uninterrupted.
However, one must be careful not to overdo it. Carried to extremes, it results in single-person teams. In addition, while solving a crisis is important, be careful not to heap praise too lavishly on the crisis teams. Otherwise, addressing crises becomes the glamor job, and the focus of the team becomes putting out fires rather than building the building. (See CompensateSuccess).
Aha! And there is a link to another pattern. We can also add sections to make these links explicit:
Related Patterns:
This pattern treats each task both as an activity and as a deliverable. Therefore:
OwnerPerDeliverable — the general form of ownership and accountability FunctionOwnerAndComponentOwner — team for each artifact, as well as the task of designing it . . . .
And so forth. For the full pattern, see TeamPerTask.
A good pattern takes the reader on an emotional journey. We want you to feel what it might be like to be on such a team, focused on one task. One goal of the forces is to touch those experiences within you that cause you to say "Aha!" and identify with the pattern.
Patterns tend to be small, local things. There is no "organization structure" pattern or anything like that. Patterns work together in rich and complex ways to generate emergent structure and behavior. An individual pattern captures local related concerns; a pattern is an encapsulation of related forces. When we apply patterns, we can do so without undue concern for other patterns in the language. In application, they are decoupled--but in the broader scheme of things, they are always part of some whole that gives them context. Patterns are like the cells in a plant; the resulting organization is like the tree or the forest that results as the cells grow, divide, and specialize. The structure for putting the patterns together in this way is called a pattern language.