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

each one.  Or imagine looking through a set of 20 changes for the smoking gun that broke the build, as opposed to finding and looking through the 73 files that were involved in those changes.

CM's rather slow evolution, at least compared to other technologies (OK, other than RDBMS systems), is largely due to the file-centric view that still dominates a number of tools.  Perhaps some can be forgiven, if they evolved from a hardware support background.  Hardware CM is primarily a part-based change tracking system to this day.  That's because hardware has a greater affinity to parts.  My mouse stops working... what part failed?  I've got no power... is it the power wiring or the power supply?  Not to say that hardware can't benefit from change packages - just that it can survive better without them, especially because of the more rigid ECR/ECO process built into most hardware development shops.

But software is functional - the menu button is not highlighted... maybe it's the specification, or are there certain conditions somewhere that have to be met, or is it a bug in the menu software, or did someone overwrite some memory, or am I out of resources, or...  Software functions span the architecture.  A bug doesn't point to a file like a flat tire points to a wheel.  But if it used to work, it may point to a recent change.  As well, software doesn't wear out like hardware, and isn't as environmentally particular.  So the failure is not fatigue or operating conditions.  Software changes usually invovle more than one file, possibly in totally disjoint parts of the system - e.g. the User Interface and the Database.  Fixes can usually be done in multiple ways - we can check for the symptom and fail, we can find the root cause and fix it there, we can disable that functionality, or if that's in the stable code, we can code around using it, and so on.

Change-based CM has been embraced too late by the industy.  And it really won't be much longer that file-based CM is tollerated, I hope.

What's a Few Mistakes
So these are some of the industry's mistakes, whether by tool vendors, process engineers or CM teams.  What's the impact?  Has this really slowed us down?  Well, yes.  In fact, YES.  Whereas operating systems have moved from very complex tuneable systems that software engineers had to customize and babysit, to plug-in-and-play software to which anyone can make substantial customizations, CM is largely still a technical mess - and in many cases we continue to build capabilities to manage the mess.

CM is complex, but so are operating systems.  Although more expansive, an OS is still not as complex as CM.  Why?  Because one deals with making well behaved processes conform to the software rules for the benefit of one or a few individuals, while the other deals with trying to get a team to work together.  In my years I have contemplated, with more than one CM system, evolving the technology into an OS platform.  Only one OS (VMS) have I ever considered evolving the technology into a CM system.  I've done neither, but keep my options open on the former. 

CM is complex and difficult.  But the user roles must not be.  Even though hundreds of users are working with tens of thousands of files, hundreds or thousands of requirements, thousands upon thousands of problem reports/defects, myriads of test cases, in multple development/support streams of dozens of products having several variants, it must not be complex and difficult for the user.

It's time to throw