Software Configuration Management Patterns

how patterns work with SCM. 

You are more likely trying to influence people who are so focused on their immediate tasks that may not have even heard of Patterns, much less, SCM Patterns. So if we're going to talk about how patterns help you to be more effective and more agile, we may want to consider thinking of how you can use patterns effectively without spending too much time on introducing the concept of patterns. After all, in the end people usually want a better software development process, not an education in patterns or other concepts. (Though through the education, they may be able to better understand how to fix their own process)

If you understand the patterns they can provide a framework for helping to explain the value in ways that your audience can grasp. For example, many readers of CM Crossroads know the value of Private Workspaces (for example) and how they fit into the development process, so I hope that the Private Workspace pattern in the book can provide an outline for you to argue why a team should use private workspaces (or anything similar) Patterns, be they from Software Configuration Management Patterns , or from other sources. Patterns are most effective in the hands of a "champion" who can interpret the patterns and translate the concepts into a mechanism that works for the existing culture. While there is benefit to adopting the pattern vocabulary, it is more important to have your organization adopt the principles from the patterns.

The "What" of Patterns and SCM
Patterns differ from other forms of describing best practices in that patterns make the relationship between practices explicit. Patterns build upon each other, and when they form a coherent unit, they form a Pattern Language, which is a guide to building something. Often you are faced with a problem for which a best practice sounds like a solution. You are then faced with questions like:

• How do I put this practice in place?
• What are the organizational and process prerequisites for this practice to work?
• What are the implementation considerations specific to my organizations tools and SCM environment?

A pattern contains the following basic parts:

• A name, [1] which describes what the pattern helps you build. The name also forms the basic for a common vocabulary. You can talk about a Task Branch in an unambiguous way if you all agree that Task Branch is what the pattern Task Branch describes. [2] Tools often have their own vocabulary and you may need to translate between the terminology that your organization and tool uses.
• A Context, which describes when it makes sense to build the thing that the pattern describes. Rather than say "Build a task branch" we need to know if the environment is one where a Teak Branch will be helpful and useful. In the SCM Pattern language, the task branch makes sense in the context of XXX. In a perfect world, we could express the context in terms of other patterns. In some cases no one has written the pattern and we settle for a prose description of your situation.
• A description of the problem, both a summary and a detailed description explaining the tradeoffs that you need to consider when solving this problem.
• A solution, that shows how to use the patterns described to solve your problem, and how the pattern solves your problem. Typically you will see a short solution and as well as a longer description with implementation details.

[1] Names are often noun phrases to emphasize that patterns are things. Some have objected to the idea of expressing