by Damon Poole

Comparing SCM Tools

People often ask me “what is the best SCM tool” or “is there a comparison of SCM tools available.” I would say that generic comparisons of SCM tools are sort of like generic comparisons of cars. Somebody looking for something that is fast and doesn’t care about gas mileage probably wouldn’t think much of a Prius.

Currently, IMHO, the SCM market is not a commodity market where the products are generally about the same. There is a wide range in both pricing and functionality. So, you really have to know your requirements and the priority of those requirements. A good initial priority to figure out is: which is more important to the organization; price or return on investment? There’s no sense in looking at all of the tools on the market if there’s not enough budget.

Determining Requirements and Building Consensus Among All Stakeholders

Generally, a good way to acquire a new SCM tool is to start from a well defined set of requirements, create a shortlist of 3-5 candidates that seem close, take a closer look and narrow that down to 2, and then do a proof of concept on those 2 and pick the 1 that most closely meets your requirements.

Depending on the size of the development group and the size of the company, acquiring a new SCM tool can be an eye-opening experience. Finding a tool that meets your requirements is perhaps the easiest part of the process. Some of the harder parts are: figuring out who all of the stakeholders are, getting all stakeholders to consensus on the requirements, getting upper-management buy-in, and securing the budget for the purchase. Getting budget and requirements to match is generally the hardest part and typically involves writing some sort of business case to justify the purchase.

Here are some typical stakeholders: CEO, CFO, Purchasing Agent, Legal, VP of Engineering, Director of QA, key developers, and Release Engineering. Some of these may seem to have nothing to do with SCM, but they do get involved in large purchases that affect the whole company. It is better to make contact with all of these folks early to get the full scope of what is required to change SCM tools so as not to get surprised later and potentially impact release schedules.

If you make a recommendation that fits the budget and best meets the other requirements, but there is still a big gap in the requirements, don’t despair! If you’ve involved all of the stakeholders and built consensus, you have a good chance of leveraging that gap to increase the budget.

Start From High Level Use Cases

When moving from one software configuration management SCM system to another, it is often the case that people concentrate on “Which of the pains that I have in my current SCM system will this new system alleviate?” This is certainly a valid question. However, it is also important to ask “What benefits will the new system bring that perhaps I haven’t considered?”

Another common question is: “Our old system is missing a certain feature to compensate for a certain problem that the system has. We’ve developed a work-around for the missing feature. Does your system have the feature that is missing in our current system?” If the new system doesn’t have the problem that the old system had, then the need for the feature is often eliminated.

A better way to compare SCM systems is to start from high level business use cases. There are many ways to implement business level use cases for software development. Some of the implementation choices include: components, streams, tasks, and branches. An example of a business level use case is: “There are different versions of software installed at different customer sites. A defect is reported by one of the customers. The defect needs to be fixed in the version that the customer has as well as all other versions which have that problem.” The implementation of this use case will be different in a component-based and a stream-based system for instance.

When changing from one SCM implementation to another, be sure to start from your business level requirements instead of mapping from your current implementation to a different implementation. The reason for this is that the high level use cases do not require a particular implementation; they can be implemented using a variety of methods. If you have currently implemented the use cases with components, it is unlikely that directly mapping this implementation into streams will be the same as starting from the uses cases and implementing with streams. For most use cases, it does not make sense to map the way they would be implemented in your current system into a your new SCM system. While it is possible to do it, the result can be difficult to set up, understand, maintain, and use. This sort of implementation will also generally make it more difficult to realize the potential of your new SCM system. In other words, you may end up with the drawbacks of both worlds and the benefits of neither. The most successful approach will be to implement the high level business requirements into your new SCM system.