Austin Hastings

Real-World Reasons for Investing in CM: At CM Crossroads, most discussion is about software CM. Many SCM practitioners are looking for help on-line, and SCM tool vendors keep adding more and more features to their products, pushing the envelope of CM. But no matter how far the envelope is pushed, software configuration management will remain a subspecialty of "plain old" configuration management.

A project baseline is the fundamental CM technique for release management. Configuration management has historically been about managing the acquisition of new products. To that end, a set of baselines is defined corresponding to various milestones in the product development cycle. These baselines reflect different expressions of the final product and include the functional, allocated, and released baselines.

A perennial question in the configuration management field is how to control databases. Databases are too big and too complex to be managed as simple objects. They have a very expressive language:  SQL. This is used to describe their structure, content, and changes. A newer issue is how to do enterprise CM. Although some tool vendors have attempted to provide support for large-scale systems, full support for complex enterprise systems is still lacking.

If your daughter ever comes home with a friendly, outgoing guy named Norbert, shoot first and ask questions later.

Some years ago, a salesman named Norbert at the SCM vendor where I worked got a call in late December from a prospect that had decided to buy from a different vendor. He asked to keep an appointment he had made for a wrapping up session. He went to the meeting with a sales proposal in hand, and after reengineering the vision of the customer, actually left with a sales agreement. Now that's a short sales cycle! 

This article is dedicated to telling you how good developing software can be. Austin Hastings describes many software development practices working together, some of which you don't have. If you like an idea you see here, implement it. After your first implementation steps, you can return here to find yet another idea to implement.

The best way to make a project succeed is to communicate effectively. When all levels of the project share the goals, vision, constraints, and plan, everyone on the team can pull as hard and as creatively as possible in the right direction. Failing to share the goals and vision underlying a software configuration management (SCM) implementation can cause it to fail.

It was way back when I was in school, walking uphill through the snow both ways, mind. That's when I first encountered Emacs and the Free Software Foundation. Because I was young and naïve and enthusiastic, I jumped in with both feet. Free software was going to revolutionize the world, and I was going to write most of it! I was naïve, like I said. I think most FOSS (free/open-source software) people get started in school, the same as me. A lot of the ideas come from the young and idealistic. Face it: young people have dumb ideas.

“Dad,” asked a young man, “my lady friends keep talking to me about being ‘involved with’ them versus being ‘committed to’ them. What exactly is the difference between involvement and commitment?”

“What did you have for breakfast, son?” his father replied.

“Bacon and eggs like always. Why do you ask?” said the son.

“Bacon and eggs, my boy, is a perfect illustration of the difference between involvement and commitment: the chicken was involved, but the pig was committed!”

Most people think they know what configuration management (CM) means. And they're right. Unfortunately, they don't all think it means the same thing. So let's look at some of the basics of CM. This isn't a "how to" article, as much as it's an "at least" article:  at least you'll know what to expect for the rest of this article.