I’m a software configuration manager who has administered SCCS, RCS, CMVision, MKS Source Integrity, MS Visual SourceSafe, Continuus, and ClearCase. What I found is that software developers usually don’t think SCM is important until they’ve been bit by the alligator. Without decent configuration management, developers make foolish mistakes in managing their code that would make the angels weep.
Working in all types of situations, little companies and big corporations, government and commercial, my observation is that almost all code shops are mom pop operations with few controls. They rely on heroics to get code out the door, not process. The worst example of this I’ve seen is Sabre, the reservation company for American Airlines. They had no idea where the code for their systems was. They were interviewing me to go find it. Consequently, they could not update their system because all they had were the executables. That’s what happens when all you think about is making your deadline.
Part of the reason that developers screw up CM is that they are improperly trained at their universities. They are given an assignment which they do solo and turn it, never to rework it nor version it. They are not trained to preserve their work nor exercised in the software development process. It’s like learning to fly but never learning to use the air traffic control system.
Another problem is that software developers tend to think of themselves as artists rather than engineers. Artists just do what they want to do and heroically save the day. Engineers build up processes which they relentlessly repeat to increase the quality of their work. Much of the bellyaching here seems more like the typical objection to having CM at all. Developers generally have a shorter term focus than their organization. They only care about delivering the release they’re currently working on. Their organization has the larger concern of preserving that release and being able to reproduce it or retreat to it. That puts developer and organization in contention.
It’s amazing to me how many shops I’ve worked where the developers bitch about doing CM but quietly spend days trying to reassemble releases they’ve lost or misplaced. They never have time to do it right but always have time to do it over. It’s like they don’t get it. If you don’t use a CM tool, it’s like not using a refrigerator for your food, laying it out on your patio instead. It’s not likely to be there in a couple weeks.
That said, VSS is OK for garage shop operations. If you only have one or two developers working on a simple application, it’s simple and free. I don’t much care for it because it appears MS just kind of winged the application, not referring to any of the rather considerable body of knowledge on SCM. If SCCS and RCS are the flint axes of SCM, then MS VSS is the bronze sword.
Personally, MKS Source Integrity is the nicest of the low end tools, most of which are pretty much the same. You don’t want to do branching in any of them. SI was easy to manipulate and it had a wonderful admin console. It took a long time to pull in the code to build a release.
ClearCase is a pretty good CM tool. You will never lose your code. Once it goes in the database, it’s like a fly trapped in amber. If you back up the database, you’re bulletproof. I’ve had my entire ClearCase application and archive wiped clean off the server and had it all back up and running in a couple days, as soon as the tape came back from the archive.
When properly installed on the correct equipment and competently administered, ClearCase runs like a champ. It’s the implementation where most ClearCase problems arise.
First, there is a bottleneck in training CC admins because they have to train on the job with developers as their lab rats. There is usually only one CC admin in a code shop. Usually there is nobody with any useful expertise who can help him in the nitty gritty of CC administration.
Second, ClearCase is not an intuitive program, particularly when using UCM. It also lacks guard rails for the users, who can hang up their client with enough determination. The problem is that ClearCase was not designed but rather evolved. Nobody modeled what developers did and worked back to the code. They built it up from the RCS utility, adding features to use the RCS better but never thinking through the whole process. Therefore, it’s confusing for the users.
ClearCase is the Stealth bomber of SCM. If you don’t train the users how to fly it properly, they’ll run it into the weeds on takeoff. Training is essential. The developers get frustrated when the tool doesn’t respond as expected or it seems complicated to figure out.
Third, ClearCase needs a good server and network. If you don’t have those, you will be plagued with problems. There are discount companies and government organizations who will spend a million bucks on the Rational tools but scrimp on the platforms which deliver it, shooting themselves in the foot.
Fourth, the biggest enemy of ClearCase is the system administrator. There’s nothing a user can do to ClearCase that can’t be undone, usually in less than five minutes. The ClearCase admin can screw things up moderately, but can fix them with enough work. However, a careless sys admin can screw ClearCase up so that it’s spitting up blood. Most of the time it boils down to permission problems within the database and views.
