Patterns come from pattern languages. We use the term "language" as an analogy. English is a language: as a language, it comprises words and the rules to put words together in meaningful ways. A pattern language is a language that comprises patterns and the rules to put patterns together in meaningful ways, in a certain sequence. It tells how to build a whole, a system. Patterns encapsulate related forces so you can focus on local trade-offs using local thinking; pattern languages are about emergent behavior in systems.
Actually, a pattern language is an outline of many ways that patterns may be put together. How they are put together depends on context. When we apply a pattern, the context changes. When someone joins the organization, or when the organization decides to build a new product line, the context may change. Depending on the context at any given time, different patterns might or might not apply.
So while a pattern language is a roadmap, there are paths to organizational growth. The exact path one takes depends on circumstances and on progress--and, of course, on the choices that people make in shaping the organization along the way. Sometimes people make bad choices, and that may mean backing up a bit or taking a detour on the journey. And bad choices sometimes result in insights that lead to new patterns and to new structures in the pattern language.
Consider that you are working in the ProjectManagementPatternLanguage. You already have ProgrammingEpisodes in place, and that you've decided that you need the pattern SomeoneAlwaysMakesProgress to keep the project from getting "stuck" or distracted, particularly by diversions. SomeoneAlwaysMakesProgress seems like the right idea; you have many tasks that go awry. But now the question is how to tailor SomeoneAlwaysMakesProgress to the particular situation. You could derail the entire team to address the problem, but that would be overkill.
So you look at SomeoneAlwaysMakesProgress where you find this:
You can employ one of a broad range of particular solutions and tactics depending on the exact forces to be resolved. The following specializations are example refinements of this pattern:
DevelopingInPairs - one person can always take the keyboard.
TeamPerTask - separate tasks into sympathetic sets.
SacrificeOnePerson - assign only one person to the distraction.
DayCare - separate the training task from that of producing software.
You home in on TeamPerTask as being a good response to the concerns raised by trying to fit SomeoneAlwaysMakesProgress into the organization. So you design a team into your organization to address the problem.
How do you staff the team? You move onward in the language and find that SacrificeOnePerson or DevelopingInPairs might be suitable solutions to the problem. Or you might look at InterruptsUnjamBlocking as another refinement of TeamPerTask: connect the team with a manager who can get the team off top dead center if the team becomes stuck on the problem too long.
Each of these pattern selections follows a natural progression through the pattern language. Most patterns can be applied one at a time. However, it pays to know the patterns in advance, and it pays to explore several patterns in your mind to provoke your instinct to the right action. Good advice from peers and, even more so, from the stakeholders in the decision, can also help guide the decision. Having the patterns at hand provides a foundation for discussion and analysis of the problem and its potential solutions.
There are four pattern languages in this book that build four "wholes". These languages are a Project Management Pattern Language, a Piecemeal Growth Pattern Language for growing the organization incrementally, an Organizational Style Pattern Language, and a People and Code Pattern Language. Note, though, that the "wholes" aren't distinct, but are different views of the same organization. In other words, a healthy organization exhibits patterns from all four of these pattern languages, simultaneously!