A solution makes sense only if you apply it at the right time. A pattern language is a way to place solutions in the context of the things you've already done.

Many books and papers talk about patterns for software, architecture, organizations and teams, and technology development, and we won't try to cover all that in this chapter. This section gives a brief overview of what patterns are about and provides references if you want more detail.

A simple definition of a pattern is a “solution to a problem in a context.” Each pattern in a pattern language completes the other patterns in the pattern language. In that way, the context of a pattern is the patterns that came before it. This means that a pattern fits within other patterns to form a pattern language.

The idea of patterns and pattern languages is originally from work the architect Christopher Alexander did in building architecture to describe qualities for good architectural designs. In the 1970s he started using pattern languages to describe the events and forms that appeared in cities, towns, and buildings in the world at large.

Alexander talks about a pattern as something that “describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice”(Alexander et al. 1977). Alexander defines a pattern as “a rule which describes what you have to do to generate the entity which it defines” (Alexander 1979). Patterns, according to Alexander, are more than just solutions. They are good solutions.

A pattern is a rule for resolving forces, but the important thing is that it fits in with other patterns.

Alexander's pattern language is “a system which allows its users to create an infinite variety of those … combinations of patterns which we call buildings, gardens, and towns” (Alexander 1979). Alexander documents patterns that exist in our towns and buildings. For example, one of Alexander's patterns is Half Private Office, which describes how to achieve the right balance between privacy and connection to office work.

Alexander's pattern languages are very ambitious, and the pattern language he has authored can give you much insight into architecture and urban planning. It was also the inspiration for the patterns in software.

Although the initial work about patterns was about building things on a human scale, we can apply the basic ideas of patterns to software development. Using and writing patterns is about the quest for objective quality. Software development involves people working together to build things. These things are often similar to other things that were built in the past. In some software development organizations, the process works well because the teams apply techniques that work and cast aside techniques that do not. In other organizations they don't, so there must be something we can learn from the successes and when to apply the techniques that worked.

The first major work in software patterns was the book, Design Patterns (Gamma et al. 1995). This book catalogs some key techniques in object-oriented (OO) design with very good descriptions about when and how to implement them. Design Patterns does not capture the full power of patterns because each pattern stands by itself, and you still need a good understanding about software systems to put them together to build something larger. To help people apply design patterns, books have been written to show how to implement these patterns in various situations (Vlissides 1998) and in other languages (Alpert et al. 1998).

Other books and writings on software patterns address architecture issues (Buschmann et al. 1996; Schmidt et al. 2000) and organization issues (Coplien 1995), but the patterns are still not connected in languages. Because they are not connected, finding the correct pattern and applying it in the correct situation require a deep understanding of the patterns and the situation. Although you do need to understand something about the patterns and what you are doing to benefit from a collection of patterns, this need for finding your way through the patterns reduces a major benefit of patterns, as a way to navigate through a set of complex trade-offs and implement a good solution.

Pattern languages are useful for documenting software architecture principles, particularly object-oriented systems because of the emphasis on structure in OO systems. They can be and have been used to describe architecture systems in other paradigms. Some of the existing pattern languages and collections about software include pattern languages that describe how to build social structures such as software development organizations (Coplien 1995; Olson and Stimmel 2002) and patterns on architectural principles (Buschmann et al. 1996; Schmidt et al. 2000). The Further Reading section at the end of this chapter lists some more examples.

This book describes a pattern language that works at the intersection of the team and the architecture: the developer's workspace and its interface to the version control system. We talk about patterns that describe how people build software on a human scale. In particular, we describe patterns that people use when applying Software Configuration Management techniques.

Patterns are a particularly useful way to think about software configuration management for the following reasons.

When you think about the way the members of a team work together, some of the first words that come to mind are process and behavior. Processes and behaviors are dynamic things, and dynamic things can be hard to understand. People are better at modeling static situations and later extending the static models to include behavior. We know how to describe what a building looks like, and given a set of diagrams, we can build one that matches the specification quite nicely. We have a harder time modeling systems that have people in them. But static structures do not appear of their own accord, and they don't do anything, so you need processes to create and sustain them; this is where processes come into play. The software architecture, the way a developer's workspace is configured, and the way the SCM system is structured are all sustained by the processes you use each day.

For a team to build software consistently, you need people to implement processes consistently. There are a few ways to get that consistency. Goodwill might work, but it is better if behaviors are enforced by the tools and the environment. Sometimes this is hard to do, and you need to allow for situations that you didn't expect; otherwise, people may view the processes as arbitrary and bureaucratic rather than useful.

When there are manual procedures, you need to motivate people to follow them. People tend to follow processes more closely when they understand the rationale behind the processes. Understanding the rationale allows people to make good judgment calls when the process does not precisely cover the situation at hand. It helps to be able to explain the process in terms of the structure it supports. But passing on a complete understanding of the system takes time.

Some static things underlie all the processes that go on in a software engineering environment. Things like source code modules, executables, and version control systems are concrete things; you use a process to change things, but the process is closely tied to the other parts of the environment.

We want to take the “simple” things that we understand and then compose them to describe how to help developers work together in teams.

Using patterns is different from other ways of looking at problems because how the patterns relate to each other is as important as the problem and the solution they solve (Berczuk 1994).

Some of the patterns here may seem obvious, but the details of how to apply them are not always so obvious. This is part of their value. Alexander says that the process of applying patterns is valuable “not so much because it shows us things which we don't know, but instead, because it shows us what we know already, only daren't admit because it seems so childish, and so primitive” (Alexander 1979).

The patterns in this book have the following parts.

The pattern chapters may also have a section that suggests ways to learn more about the topic of the pattern.

This section briefly describes how the patterns in this book are organized and then discusses how to use the book.

As you read through the patterns, you may find that some match your current practice, while others do not. Teamwork is a complicated thing, and a there is no simple cookbook-like approach to using the patterns in this book that will work for everyone. The best way to approach the patterns is to read through them all until you have a high-level understanding of them and then work through the patterns that are particularly relevant to you. After you have done this (or if you want to start attacking your problems now), here is one approach that we suggest starting with.

Each pattern can also stand on its own to some degree.

This book shows one path through the patterns, that for doing mainline development. Parts of the language may be relevant for other situations. For example, the Private Workspace pattern will be useful to you regardless of the sort of environment you use.

These patterns are independent of the tools you use. Some tools support some of these concepts explicitly, some less directly. But the concepts have proved themselves useful in many development environments. For example, some tools don't support branching and merging as well as other tools. Clearly, you do not want to do these practices routinely without tool support, but at times even rudimentary support for branching will make your life easier than avoiding branching. Where appropriate, we discuss tool support in general terms so that you can see what features you need if you are looking for tools. We discuss examples using common tools, but we try to keep them at a level that will allow the book to stay current as tool interfaces change.

The pattern language in this book focuses on a team of developers working off of one codeline (or a small number of them) for any given release. These developers work in their own private workspaces.

Some issues of codeline organization for large projects we do not address in full, but the book is more about how things work in a local development environment. For a wide range of systems, the principles hold equally well.

Figure 3-1 shows the patterns in this language. The arrows show the relationships between the patterns that the context and unresolved issues section of each pattern describe. An arrow from one pattern (A) to another (B) means that pattern A is in the context of pattern B. This means pattern B is most useful once you have already thought about using pattern A. The arrow from A to B also means that pattern A needs pattern B to be complete.

Figure 3-1. The SCM pattern language

The patterns in this pattern language can guide you toward establishing an active development environment that balances speed with thoroughness so that you can produce a good product quickly. After the first two patterns, the patterns fall into two groups: patterns that describe the structure of your workspace and patterns that describe the structure of your codelines.

There are other approaches to development than the Mainline approach we discuss here. The Mainline approach works well in many circumstances, and other approaches may share many of the same patterns. It is important to remember as you read through these patterns that, although we hope this advice is useful, only you understand your set of circumstances. Apply the patterns with care.

The patterns in the language can be grouped into two sets: codeline-related patterns and workspace-related patterns.

The codeline-related patterns help you organize your source code and other artifacts appropriately, in terms of both structure and time

The patterns relating to codelines are^[1]

Figure 3-2 shows these patterns.

Figure 3-2. Codeline-related patterns

Figure 3-3 shows patterns related to workspaces.

Figure 3-3. Workspace-related patterns

The patterns related to workspaces are

This chapter gives you an overview of pattern languages in general and the pattern language in this book. The rest of the book defines the patterns.