Those of you familiar with my work may be asking yourselves why an expert on J2EE software architecture would be writing a preface for a book on software configuration management (SCM). After all, the two disciplines couldn't be farther apart, could they? J2EE architecture seems lofty and exalted, while SCM might appear to be something that is down in the muck of the trenches of software development. In fact, nothing could be further from the truth. Over the years, I've often found that customers that I work with who have problems with J2EE application architecture usually have serious problems with SCM as well.

The reasons for this curious coincidence are twofold. First, many people have a hard time dealing with change in general—be it moving from a set of architectural practices that no longer apply in a new environment like J2EE, or moving from a software development process that worked in one environment but may not work in all environments as well. Thus they feel that if their SCM processes worked in their last project, they must work in their current project—regardless of the fact that the technologies, timescales, and methods employed in designing and building the two projects may be radically different.

Second, people often want a small set of simple rules to govern all their activities. However, taking a too simple approach usually leads to problems at the edge where abstractions meet reality. Whether the issue is understanding why a particular J2EE construct, such as an Entity EJB, may work in one circumstance but not another, or understanding why it is important for developers to have their own private workspaces in which to do development and integration when, after all, you have to integrate the code from your developers at the end of the day anyway, the problems are the same. In both cases, a simple rule (use Entity beans, use a build script) is perfectly good advice, but it must be tempered in the forge of experience because in its raw form it is too brittle to use.

What mathematicians and scientists have begun to discover in the last two decades of research into chaos and complexity theory is that, although systems built with rules that are too few and too simple are usually stagnant and predictable, adding just a few more rules can often lead to systems of startling complexity and beauty. These are systems that can be seriously perturbed by outside forces and yet can reconstitute themselves so that the overall scheme remains whole. The book you hold in your hand provides a set of rules for SCM that have that kind of flexibility.

Steve and Brad have developed their advice on dealing with SCM as a system of patterns. As they tellingly reveal early on, the strength of a system of patterns lies not in the individual patterns themselves but in the web of relationships between the patterns. The authors have developed an interlocking mesh of patterns that individually cover the most common practices in SCM. However, they more importantly show how the forces that lead to each solution are not completely resolved in each pattern—that you need to carefully consider how each SCM practice is tied to others, to keep from locking yourself into a prison of your own making.

For example, you may want to look ahead to the wonderful advice given in their first pattern, Mainline (4). This seemingly prosaic advice (that developers should work on a single, stable code base) is something that I have found many groups, including those in large, successful corporations that have spent millions of dollars on implementing processes, have somehow failed to grasp. This is common sense, well applied, and that is what makes it uncommon.

Likewise, the advice given in Private Workspace (6) and Private System Build (8) is nothing less than two of the key ideas that have made modern Java IDEs such as VisualAge for Java and IBM WebSphere Studio so useful and popular. When I am asked (as I am nearly daily) why developers should choose one of these IDEs over development at the command line with traditional code editors and compilers, the fact that these tools not only allow but actively encourage this style of development is a key factor in how I phrase my recommendations.

So, I trust that you find this book as helpful and enlightening as I do. I've been introducing people to a number of the patterns from this book since their first publication in the Pattern Languages of Programs (PLoP) Conference proceedings several years ago, and I've found them to be invaluable in setting the stage for frank and constructive discussions about how to perform SCM the right way. These patterns have been my sword for cutting through the Gordian knot of complex SCM issues in tricky customer engagements—I hope that you will soon begin to wield this weapon as well.