CM: The Next Generation

number by the end of the decade.

What does a third generation tool have to do? For starters, it has to reduce the CM administration team significantly. If not, the tool will continue to cater only to a few who can afford it. It has to reduce the risk of introduction. Consider a tool which requires you to invest heavily just to assess the level of return it's going to give you versus a tool, which for the cost of your investigation is fully deployed and returning an even greater investment. Which one do you think will win out? Marketing aside, that's easy.

And what about CM Maturity? Countless resources are spent evolving, and training users on, branching and labeling strategies, synchronizing distributed development and putting together Version Description Documents or traceability reports. Lots of room for improvement there. Reliability and availability not only affect end user productivity, but can significantly make a difference in the case of a disaster, be it a disk crash or a terrorist attack. Process evolution will apply not only to the basic CM model, but will expand that model into the areas of Requirements Mangement, Work Breakdown Structures, Test Case Management and Test Run management. Process specification must also be simplified.

With all of these advancements, there has to be a focus on ease of use issues. Whereas the advances for second generation CM naturally compounded ease of use issues because of the wider scope, third generation CM advances should generally work in the opposite direction. The tendency is to reduce administration and increase CM automation. These goals in themselves will improve ease-of-use. However, a vastly advanced standard for the overall computer industry has set the bar high for ease-of-use issues.

So lets look at each of these areas in more detail.

CM Maturity

Since branching and labeling were first facilitated, strategies have evolved which sometimes tend to make your CM architecture resemble a plate of spaghetti. Why is this? The key reason here is that branching is an overloaded concept. It's not just used for parallel development. It's used to collect files into a change, to collect files into a promotion level, to help identify active work before it's checked in, to create patch and variant builds. The list goes on. The key point here is that the basic real-world objects of CM often lack the underlying data capabilities, so branches are used. Branches are a powerful concept.

With clearer identification of the most frequent branching patterns, a shift is coming. The "main trunk" model of CM will give way stream-based models for both support and development streams. While there may be the odd sub-pattern attached to the stream-based model, for the most part, the drive to reduce complexity, and the realization that complexity can be reduced dramatically, will drive the effort to clean up branching.

This will require new first order items. Rather than having a baseline as a labeled branch, a baseline will be a first order item. We see this in more than one tool already. Similarly, build objects will exist which allow you to collect changes that are to be applied to a baseline to create a patch or variant load - perhaps a customization for a particular customer.

Rather than branching and labeling to collect files of a change, you'll see more and more tools introducing change packages. Many will get it wrong, and some already have - using the task or problem/issue as the "change" object. This won't work primarily because a task or problem often requires several changes over time to implement. And it's often desireable