The implementation of a CM tool can become a major systems development and implementation effort. What starts as a small project to secure the firm's source code can evolve into a major effort to improve programmer productivity. The CM practitioner is often swamped with non-stop requests from the developers who will often only accept a CM system if it is smart enough to do a lot of work automatically. In a large company different development teams may have very different requirements and software development lifecycles (e.g. PowerBuilder vs. Unix C++). These demands can lead to months of scripting and the development of internal/external websites to track build and deployment status. Read on if you would like to see a framework for evaluating requirements for the successful implementation of software configuration and release management systems.

Interfacing requirements tracking systems ...

Many of us have had the task of interfacing requirements (or defect) tracking systems with enterprise wide software configuration and release management systems. Despite our best efforts these tools often do not reach their full potential because developers often fail to follow the process and specify requirements (or defects) in a disciplined and reliable manner. When deadlines get tight the process gets bypassed and the nice requirements database is quickly rendered useless because it has not been updated. As tools guru's we often criticize our development colleagues for not being professional at following the Software Development Lifecycle. As Quality Management advocates we believe that the developer could have still delivered on time (with fewer defects) if only he/she had followed the process. If CM practitioners did the development work, we would track our requirements reliably!

Practicing what we preach ...

Of course the implementation of any robust software configuration and release management system also involves requirements. For example do developers need to manage multiple variants (e.g. branches) of the code? Of course we all know that the day after we install a good CM tool the developers always come up with new features that they insist are absolutely necessary in order to make the CM tool worthwhile for developers to use. I remember the first time that I implemented a ClearCase system for a group that had used CVS. The development team had a number of scripts wrapped around CVS and they insisted that we write scripts to make ClearCase act, look and feel like CVS! This effort was very painful and obviously not very successful. Instead of making a tool mimic another tool we should have managed the developers requirements! But of course this is often not a trivial effort. There are many types of requirements.

Creating a topology for requirements...

In any requirements tracking effort a topology to organize the requirements is really essential. Here is the model that I have found most helpful.

1. Reliability/repetition is a top priority. It is a basic assumption that if we build a release one day we can build the EXACT same release on another day. As simple as this sounds, many companies cannot reliably rebuild their releases (even for code that is currently in production). The CM tool itself must be reliable as well.

2. Quality of the application. A good CM tool will help us develop software that is defect free. The CM tool must also be a defect free application. Developers will not use a CM tool if it is unreliable and suffers from obvious defects. In fact developers are often extremely motivated to "break" a CM tool as an excuse for not using it! (If only they were as conscientious at unit testing their own code.)

3. Ease of use is important to everyone. This is a difficult requirement to meet. The more robust CM tools are harder to use. The more complicated the developer's requirements, the more likely that the tool will not be easy to use. Mistakes can cause significant loss of time and efforts. In my work, we have pushed hard to have every developer take the 2 day hands-on class (that I teach). That means that sometimes I teach 12 people in a classroom for 2 days and sometimes I meet a few developers in a conference room (after 5 pm) with my laptop. We're flexible on format, but everyone must understand the basics!

4. Productivity is becoming essential to every organization that has been forced to reduce staff in our challenged economy. Many CM tools facilitate parallel development, separate "sandboxes", extensive history (e.g. metadata). A good CM tool should make us more effective at doing our jobs.

5. Time Machine. A good CM tool should allow us to set the clock back and have the environment EXACTLY as it was 6 months ago when we completed the release that is in production today. In fact we should be able to make a 2 line change to a release of code and be absolutely certain that nothing new has gotten into the release. Ideally, we want to be able to see the latest and greatest code in one window and in another window we should be able to see the code exactly as it was six months ago.

6. Admin. A good CM tool should have solid Administrative features to allow for controlling access and dealing with problems that may arise. For example, we should have tools to deal with data repository corruption and disaster recovery.

7. Cost is important too. In a world where open source means free, we don't want to pay thousands of dollars for a good CM tool. Of course CM tool vendors may have a different view on this issue.
The CM tools (and processes) that we implement consider all of these requirements at varying levels.

Your organization may have other requirements than these. What is important is that you clarify and communicate your requirements. If you have picked a complex tool then it is important to communicate why this is necessary and to offer training to help developers deal with the implicit changes in the way that they will be working. If you have picked a simpler tool (e.g. SCCS, RCS or CVS) then you should communicate the tools limitations and liabilities. CM tools without the benefit of an underlying database are more likely to loose versions of code due to corruption. What is worse is that this may not be discovered until long after the backup tapes have reused!

Why can't we track our requirements ...

As soon as we successfully implement a CM tool, most developers start recommending ways to improve the process. While this obviously great, it also can result in months of scripting efforts for the CM practitioner. In a large organization the requirements of one group may be very different than another. In my work I have seen small developments teams who were great with a complex usage model that would have been a disaster in another group (within the same company).

What are our requirements?

We use an assessment questionnaire to determine user requirements. We ask about the languages, platforms and technologies used in the development effort. Then we ask about the number of developers, release cycles and the size of the actual code base. The team is required to write a CM Plan that documents their method for using the CM tool. We provide a template that makes this effort easy. Each team has the flexibility to determine their own usage model, but it must be documented (and posted on our website). This includes naming standards for Version Labels, branches, commands that are permitted (or forbidden) and release procedures. We require each group to have a buildmeister (although it is often best to rotate this responsibility to each of the developers).

Understanding our goals and priorities ...

While the requirements may vary from team to team, the overall goals are persistent throughout the entire organization. For example, we want all of the source code to be secured, all build and runtime dependencies must be documented (and secured!). The developer is required to demonstrate that every production release can be rebuilt if necessary.

Values that drive our requirements ...

Explaining why this is important often comes down to communicating our values as an organization. My grandmother worked for the Long Island Railroad cleaning the inside of the trains. I used to go with her a few times a year and she would give me a rag and I would wipe the seats down. (I was too little to reach the windows.) Everything that I ever learned about working hard came from that early experience. Grandma washed those trains like they were her living room. Grandma was very conscientious and she had the integrity to work hard, even when no one was looking. Grandma taught me to value hard work.

The field of Industrial Psychology teaches us that conscientiousness is the personality trait that is often the best predictor of success on many (or most) jobs.

How do we measure up ...

Most of us react to the environment where we work (and live). If we are happy we do a good job. When we are disgruntled (or at least not motivated) we do just what we are forced to. I have seen many CM systems that were technically correct, but the code was not really secured. The CM practitioner met the letter of the law, but not the spirit. My grandmother made a big difference in the lives of the people who were dressed up and heading to work each morning. During this past year I had the joy of caring for my (96 year old) grandmother, in my home, during what I knew were her last days. When she was disoriented, I often reminded her of cleaning the trains. She always smiled. She was obviously proud of this hard work.

The role of the CM practitioner is to manage and meet the constantly shifting requirements of the development organization. At a time when hackers can take down entire networks and companies must plan for emergency relocation of vital services, source code control is becoming nothing less than an essential requirement for our national security. How we approach requirements management affects our organization, the nation's economy and most of all ourselves.  

You can reach Mr. Aiello by email at raiello@acm.org

Trackback(0)

TrackBack URI for this entry

Comments (0)

Subscribe to this comment's feed

Write comment