CM: THE NEXT GENERATION of Quality in your Configuration

products.

What's My Job

"Hi,
I'm Bob, a programmer on the project.  My manager gave me an API that I have to implement.  I just want to write the code in a few files in my directory, compile them and hand over the results.  I don't want a CM tool getting in my way.  I know what I have to do and I have the tools to do it!  How are you going to make my job easier?"

Here we have a programmer who doesn't understand his job.  Like it or not, the
programmer will have to do the following things in addition to the steps he perceives in his mind:

• Make backup copies of the code in case of disk crashes, etc.

• Put Copyright notices into each of his files

• Run tests to ensure that the resulting code is working.

• Have others run tests to ensure that the API implementation is successful

• Keep track of problems that others have found in the implementation

• Fix these problems

• Let others know when the problems are fixed

• Identify changes to the API requirements for the next release

• Implement and test those changes while making sure that the original release still works.

At this point, the programmer realizes that he needs to keep two versions of his implementation: one for the current release and one for the next release.  Not only that, but he has had to keep track of which requirements (i.e. versions of the API) apply to which release.  And which tests are to be run on each release. Then there are the problems that are reported: do they apply to the current release or the next one, or both?  And what happens when he fixes a problem in the next release and then realizes that it has to be fixed in the previous release as well?

So, maybe the programmer didn't really understand his job that well.  Quality requires that each team member understands the job assigned to his/her role.  Well defined and well
understood roles allows the puzzle to fit together without any missing pieces.

Still, he argues, he could just maintain two parallel directory structures, one for each release.

Hiding the Complexity

The programmer has accepted that his original job understanding fell a bit short, but has developed a directory structure to hold the API requirements, test scripts, code, problem descriptions, etc. in a nicely ordered fashion.  He's comfortable.  He doesn't really need a CM tool. That is, until someone comes to him and asks:

• That problem that you fixed, which files were changed to fix it?

• Can we do a code review on that fix?

• We delivered our product 2 months ago to customer X.  Is that problem fixed for that customer?

• Can you propagate the change you made last month to the next release?  Are there any other changes that should be propagated?

• By the way, we'll be shipping release 2 next month, can you start work on release 3 tomorrow?

Bob is a smart programmer.  He knows he could continue to evolve his own processes to help him to track things.  But now he realizes that this is a much larger task than he originally thought and that he could use a few tools to help him out. His world is just becoming a bit too complex.

Many programmers will be able to keep all of the complexities in mind as they learn them.  Many will not.  The CM tool needs to hide these complexities.  Complexities in the process and at the user interface will lead to human error for any number of reasons.  A good CM tool will hide the complexities by ensuring that it has sufficient context information to allow the user to