CM: THE NEXT GENERATION - Don't Let Our Mistakes Hold Us Back

costs help prevent it from surviving the current economic crisis.  When you look for technology, don't start from where you were 5 or 10 years ago - look at the market anew.

A similar situation arises in building your solution in-house.  Nortel, did this in the mid-'70s, and had perhaps the best CM system of its time, running on an IBM mainframe.  AT&T had similar success and even took their system commercial at one point.  IBM as well.  These were great systems and while Nortel, AT&T and IBM are able to finance such ventures, they are not their core competence.  These companies did so in their day because there were no other solutions that compared favorably.  They held on to them for long periods and built large teams around them, even though they started out as very small team efforts, even through initial maturity.  But as the teams grew in size, the business case for them became less compelling.  This is why Nortel started moving away, about a decade ago, from its in-house CM, though I'm sure much of it is still in use.  They had the expertise, but they didn't manage the overall costs well.  Less than $1 million to create a CM tool that saved them millions - then they grew the team so that it was too expensive to evovle.  Rather than try to spin out the group into a separate company, or reduce it back down to its original size of a dozen people or less, they abandoned their own in-house tool and moved on to new technology.  A good move perhaps, except guess what... Mistake #1 followed by Mistake #4.

Change Control, Not File Control
CM tools evolved in the late '60s and early '70s, with the advent of SCCS and other less known tools.  These would allow you to store multiple versions of a file in a single file, delta compressed. This capability evolved and evolved - but, with some exceptions, remaining file based.  A few organizations recognized the need for change-based CM, tracking changes, not to file, but which were implemented by revisions to a set of files.  Even Nortel's home system realized this (hence it's longevity).  But commercial vendors, with the exception of a couple, pushed the file-based agenda. 

Mistake #5:  Change-based CM, not File-based
It wasn't until the late '90s that most vendors conceeded that change packaging was essential and file-based CM just got you into trouble. So the scramble started to improve tools.  Few did an admirable job.  Most looked at adding a separate concept called a change package or task or similar so that files could be tied together into a change package, but required the use of additional tools or user interfaces.  As we turned the century, some realized that there were actually some benefits to looking at things from the change perspective rather than from a file perspective.

Very few CM tools have grown up with or have moved to a change-centric focus.  As a result, most developers still look at file-based tools and what improvements can be made from a file-based perspective.  A change-centric CM tool makes life so much easier.  It makes CM natural - not an extra process that developers must put up with.  In fact, it greatly reduces their effort.  Imagine merging a change from release 3 to release 2 by selecting the change and saying "merge please".  This is so much different than identifying all of the files that changed to implement a feature, looking at the branching history of each and figuring out which files need to merge and then merging