February 10, 2009

The Benefits of SCM


These days most developers know what SCM is, and many know how it works; however, I frequently encounter developers who have a poor understanding of why they use SCM, or what it enables them to do. If you're a developer reading this, the odds are that you're think I'm not talking about you, but  maybe I am; if you think the benefits of SCM are things like not losing any file content, atomic submits or even fast, reliable, cross-codeline merging, then I am definitely talking about you.

The crux of the issue is that those are not benefits, they're features, and too often developers get hung up on the features of one SCM system vs. another when they should be paying more attention to the benefits; the features are only significant in so far as they help us to realize the benefits.

So, what are the benefits? Well for me they are things like building global teams, improving developer productivity, and reducing the defect rate. The features of our SCM systems must support our goals, or there's simply no point in having them.

We do software development in order to get products to market; so if SCM is going to be of any benefit at all it must affect that process in a positive way. The benefits then lie in solving problems with the development processes and environment, and these days development takes place under some very challenging conditions.

Modern software development is rarely performed by a small, hard-core, team of experts who lovingly hone the product to perfection before releasing it; it's far more common for product development to be spread across teams, timezones, and even companies. That makes it more difficult than ever to extract maximum value from your SCM system, and ensure that it benefits your business; so those in charge of development programs must stay focused on realizing the benefits of SCM and not just going through the motions for the sake of conformity with so-called Best Practice.

To my mind, the most significant benefit of SCM in the modern development environment lies in its ability to foster the development of global teams. Think about that: it's one thing to say "we have one development team in London, one in San Francisco, and another in Mumbai", but it's quite another to be able to say "our development team is distributed around the globe" (that's "development team", singular). To create an environment where developers, who have never met in person, build collaborative relationships across timezones is a non-trivial exercise and SCM systems are a key part of meeting that goal: what other part of your infrastructure allows people to see so clearly what others are working on, to gain real-time access to their changes, and to anticipate future problems?

Of course, many SCM systems are 'distributed', in the sense that they are built around the idea of exchanging data between multiple repositories. To my mind, the Distributed vs. Centralized argument is not technical, it's entirely philosophical: one strives to create local teams that co-operate, while the other aims for one global team that collaborates. In my experience collaboration is more powerful (and more elusive) than co-operation, and what the distributed systems gain in localizing development, they lose in undermining the global team.

Of course, it's also possible to use those systems that advocate a central repository (such as Perforce), in a way that creates barriers between teams and individuals and prevents the global team from coalescing; but with careful planning, it is possible to use your SCM system to help you build something special: a truly cohesive global team.