Any complex piece of software is the product of a team of people who need to work together. They must coordinate ideas and code so that each team member can make progress without interfering with the work of other people on the team. For example, you might make a code change that implements a feature that you are responsible for, but if you don't communicate or coordinate with the rest of the team, you may break some other team members' code unexpectedly.

Some development organizations take one of these extreme positions.

Of course, neither of these sounds entirely correct, but we follow them anyway because each sounds like a good approach, and if we have been burned by another approach in the past, following one of these philosophies may lead us to believe that we are avoiding problems we've seen in the past. Consider the number of times you have experienced one of the following situations in a software organization.

Agile software development approaches acknowledge the reality of change in software development and suggest that you adapt your development methods to acknowledge that some projects have high levels of uncertainty and risk. In agile approaches, “control focuses on boundaries and simple rules rather than prescriptive, detailed procedures and processes” (Highsmith 2002). Often people think of configuration management and version control as process-heavy things that might get in the way of the “real work” of coding. For many projects, SCM does get in the way, and some organizations overcompensate and don't use the tools to help them because of a fear that a process is inherently limiting. Other organizations want control and have so much process around version control that they hurt themselves. The right amount of version control is appropriate in agile projects. The approach to configuration management and version control that this book describes is most suited for agile teams, where the development pace is rapid enough that you don't want processes to get in the way, but you don't want to be stepping over each other either.

Often conflicts about software configuration management arise because of the difficulty of determining how much structure you need. Too little and chaos reigns, too much and the environment becomes stagnant. Highsmith describes how this debate is really about balancing adaptation with anticipation (Highsmith 2002). Highsmith also observes that “one of the reasons for the divide between process and practice is often the perception that an onerous process reduces the incentive to use any process.” This reflects the reality that what matters is not your process as much as what people actually do.

A common area where the disconnect is obvious is in how a company handles branching. A company's branching model often does not match its business model. A company that wants frequent product releases may have complex branching structures and need time-intensive merges. Another company may have many customers using independent releases but have few branches, trying to manages the differences between the customer versions in some other way. This often happens because they misunderstand their tools and techniques or because they are striving for some sort of ideal model that is inappropriate for their situation.

Much of the heavyweight application of SCM techniques comes from a desire for perfection. Seeking an ideal isn't always the best approach to a successful project. As Gerald Weinberg says, “Reasonableness saves enormous amounts of time” (Weinberg 2002).

Many good software development practices exist that current developers just don't follow, even though these practices have been around for a while, as Steve McConnell comments (McConnell 2002). Incremental Integration and Source Code Control have been around since 1980. These are two approaches that you can add to your process and get a major gain in productivity with a minimum of effort. This book shows you how.

Software configuration management processes and tools support at least two classes of tasks in the development process: management and day-to-day software development (Conradi and Westfechtel 1998). The management-related tasks that Software Configuration Management supports include identification of product components and their versions, change control procedures, status accounting, and audit and review. For day-to-day activities, SCM helps you, as a developer, with version control functions that allow you to record the composition of versioned software products accurately as they are revised, maintain consistency between interdependent components, and build compiled code, executables, and other derived objects from their sources.

This separation between management and development activities doesn't make a lot of sense. The things developers do are necessary for the management support tasks to be meaningful; you can't identify product components if there is no product to identify. At times the SCM process—particularly the management support aspects—seems to impede development work as opposed to enhancing it. One reason for this is that the SCM processes are often defined with the goals and needs of management first and ignore the daily needs of the developers. Another is that the processes don't use the appropriate techniques, out of ignorance or a (misguided) attempt to avoid potential risks.

There are many reasons that organizations make the same mistakes in applying SCM practices and, as a result, frustrate developers and reduce productivity and quality. One reason is that some organizations lose sight of the real goal of their work. The goal of a software development organization is to develop software that solves a customer's problem and to deliver quality software. The definition of quality is important here, so we use the definition “value to some person” (Weinberg 1991).

Some organizations put a lot of energy into doing things that don't help with the process of making useful software. Some of these places talk a lot about “the customer” and “quality” and “productivity,” but their actions don't always support those spoken goals. Gerald Weinberg describes this sort of situation as a lack of congruent behavior (Weinberg 1986). Noncongruent behavior confuses people and hurts quality.

Some organizations make decisions that have more to do with avoiding change and expense than with writing quality (and income-producing) software. Often these decisions are well intentioned; they end up being counterproductive because they are made without understanding all aspects of how developers work and without considering of how their decisions affect other parts of the development process. A team may not create a branch when a branch would appear to be helpful because the manager of the team had earlier experienced branching as being problematic. These survival rules are useful for reducing risk, but when overapplied they can increase risk. Gerald Weinberg says:

Although members of a team spend large amounts of time and energy thinking through how to design a software component, teams rarely put the same effort into thinking about how they work. In particular, many source control practices often don't fit the needs of all their users. Often the SCM practices are established at one point and are then continued somewhat blindly. One reason that SCM practices don't adapt to a team's needs is that some of these practices are organization wide, and it is hard to justify, not to mention implement, global change.

A reason that practices may not meet the needs of the users in the first place is that the easy target for changing the version control process is the tool, and discussions of how to work with version control often get lost in deciding what tool to get. Sometimes organizations decide that what they need is a high-end (and powerful) tool such as ClearCase. When they know they can't afford that, they decide they shouldn't get something else, and they continue to use a tool that does not meet their needs—for example, Microsoft Visual Source Safe.

In the quest for a good solution, we often lose sight of the fact that many small-scale changes can have a large impact on how we work. Although a new tool might make a big difference, using your current tool effectively and working within its limitations also help greatly. Another reason that source control is ignored is that you can resolve most source control process issues through manual processes. Although this is work and has a cost, it is one that most managers don't see. As when planning for a product, you should consider the developers as a class of users for the SCM process. “People who are left out of planning invariably turn up late in a change project to haunt you” (Weinberg 1991). In this case, the “haunting” will be visible in terms of frustration and decreased productivity.

This book will help you understand some of the techniques and processes of SCM and how to apply them in a way that allows you to work more effectively. Many of the techniques can be applied incrementally and locally so that you don't need to change the entire organization to improve the way you work. It may also provide you with a means to explain how some day-to-day practices can support both your needs as a developer and the larger needs of a someone managing a product release.

Encompassing the management and development support aspects of SCM, configuration management, and in particular version control, plays a role in supporting the work of teams. Version control can certainly benefit a one- or two-person workgroup, but when you have more people than can comfortably manage to communicate to each other everything they are doing on a project, you need an infrastructure to support communication. A version control system is the way teams can get the answers to questions about who made recent changes, when something broke, what code customers are using, and what components are related. This is what we mean when we say that software configuration management serves as a mechanism for communication, change management, and reproducibility.

To develop software you need to do obvious things such as define requirements, develop designs, write code for the product and for tests, and write documentation. The hardest and one of the most important things that has to happen is effective communication. Communication is not just sharing status and general information but also sharing enough detailed information about what people are doing so that teams can work together and be more productive. Although engineers often spend a lot of effort on design and implementation decisions, engineers and their managers often leave teamwork issues to “just happen.”

You can realize important improvement in team productivity and software quality by using the appropriate version control practices. Unfortunately, many version control practices are often established without a good consideration of the things that influence how code is written. Some of these things are as follows.

For each of these influences you could change the factors themselves. Put your whole team in one city (or in one room); fix the product architecture to reduce coupling; buy a “better” SCM tool. These changes can be expensive. It can also be expensive (though not as obviously) not to fix the other problems. We often find that the costs of changing a tool, for example, are very visible, but the costs (in productivity, morale, and so on) of using the wrong tool badly are hidden. It may be easier to adapt the way you use Version Control to the way people work than to change the environment. Chapter 2 discusses the role of organizations and teams in more detail.

Our goal in this book is to point out the solutions that are effective, given the environment you must work in. You may be surprised by the improvements you can find by making small changes in process. You will also identify aspects of your environment that you should change. In the end, we want to help you build better software faster, not force you to use a particular process.

Some of the techniques are things that affect how the team works and may need consensus or management buy-in. Some are practices that you and one or two colleagues can do on your own.

There are many aspects to team communication, including organizations or management. These things do need to be considered because they have an impact on how people work. This book is about the tools and techniques you can use as a person developing software to work cooperatively with members of your team and members of other teams. The way teams communicate their work products to each other is through their Software Configuration Management and Version Control practices.

Like many things in our discipline of software development, software configuration management means many things to many people. This section discusses some dimensions of SCM and highlights the aspects we are concerned with.

SCM serves at least two distinct purposes: management support and development support.

A standard definition of software configuration management includes the following aspects (Dart 1992).

Ideally, a configuration management process should both serve broad organizational interests and make the work of a developer easier. A good SCM process makes it possible for developers to work together on a project effectively, both as individuals and as members of a team. Although various tools can make the process simpler, tools alone are not enough. Successful development organizations also use certain patterns for software configuration management .

With respect to team interactions, a successful configuration management process enables the following.

Attaining all these goals involves compromises. A cynic could paraphrase Otto von Bismarck's remark, “To retain respect for sausages and laws, one must not watch them in the making,” to apply to software systems and processes. We need to watch how our processes evolve and attend to what works and what does not work, and by leveraging the experiences of others, we can improve.

Version control is an important part of making team software development work effectively. Version control practices help people work on the same components in parallel without interfering with each other's work. Software Configuration Management and Version Control practices allow you to do things such as the following:

The next section identifies in a development project some of the tensions that interfere with establishing good SCM practice.

The first question people ask when they talk about version control is, What tool are you using? This is a practical question that reveals the important impact tools have on the way we work.

Although the tool influences how you work, it should not be the main concern. Of course, tools with a feature set that matches your needs make things work better. But the most important thing is to balance the capabilities of the tool with the needs of the organization and the developers. It is critical to make the processes easy so that people will follow them. Another aspect that this book shares with advocates of agile development is that it is the people on a team and what they do that is important, or as the Agile Manifesto says, “Individuals and interactions are more important than processes and tools.”

When you find that an everyday practice needs a large number of (hard to remember) manual steps, you may want to question the capabilities of the tool or the value of the practice.

Appendix B describes some common tools and how to use them to implement the patterns using the concepts of the tools. Appendix A provides even more information on SCM resources.

Tools, Product Architecture, and Organization are all important aspects of the software development environment that we need to take into account when building software systems, but when we let them drive the process at the expense of delivering quality software in a reliable manner, we get into trouble. There is a lot to do besides coding—documentation and testing are part of the process, and quality and reproducibility are things that help get a product out. The next chapter discusses in more detail the other pieces of the picture and how SCM fits into this picture.

This book approaches the problem of using software configuration management and version control by looking at the overall environment within which you use version control and by demonstrating how to solve problems after considering your specific environment.

This book places a number of well-documented best practices in the context of a team's work style and the constraints of your organization. This book does not present a set of rules you should follow but a set of practices that work together (with variations).

The practices are cast as patterns. We discuss patterns in general in Chapter 3. You don't need to understand patterns to use the ideas in this book, although you may get an added benefit if you do.

How do we improve the way we use version control? The next chapter describes how a pattern-oriented approach is helpful.

This book is not about software architecture or process per se, so we cannot go into as much detail about these issues as we would like. The following references provide more detail.

An important aspect of improving processes is detecting the problems in an organization and influencing people to change.