Once, a really long time ago - at least according to the Judaeo-Christian tradition - Adam was charged with naming things. Let's pretend he didn't and the family is talking around the campfire.

The father, talking to his son, says, "I am going to snarf an elephant for blurb. Do you want to greep a mouse for me?"

"What is a greep?"



"Greep? I said get me a prud. How else can I capture a cat?"



"Is this a prud?" the son asked, holding up a club.



"No! I want that," he said pointing to a vine.



"Oh, you mean rall a foop! How can you snarf a cat with that?"



"Why would I want to snarf anything? My truff is drouu," the father said pointing to his stomach as a rumbling sound ensues.

This conversation would most likely descend rapidly into physical violence. Not only are they not using the same words for the same things, they change the words for the same thing seemingly at random. That is why the "first man" was charged with naming everything. Without that consistency, there could be no language beyond pointing. And thus was born the first standard.

Naming Standards
This also means that the first standard was a naming standard. While I have never seen an industry-wide naming standard, there are references in most development standards from IEEE, ISO, EIA, etc. that require projects to have a naming standard that covers at a minimum:

• program names
• directory names
• function/routine/class names
• variable names
• release names (at least the numbering part)

So, the first reason we have standards is to foster communications. A derivative reason is so that we can find things. If you know that "fwd" is an acceptable abbreviation for "forward," then looking for something called "forward look-up" could reasonably be found under "ftwlookup." This is also part of a naming standard. It presents one with a list of acceptable alternatives, as well as when and where they may be used. A second derivative reason is to allow lessons that have been learned to be codified and passed on to future generations so they do not have to be constantly rediscovered.

Once we get into development, there are coding standards that detail how code should be constructed, the style the code should appear in, when code should be decomposed, modularized and/or refactored, where code should appear in directory hierarchies, etc. There are similar standards describing how requirements are to be documented, designs are to be constructed and test artifacts are to be created/organized.

Many of these standards came into being in response to problems brought on, either directly or indirectly, by human nature and the scope of communications (the number of people involved). When there are only a few people involved in an endeavor, communication is relatively easy and the personnel involved can communicate quickly. They can even coin new terms where everyone agrees on the meaning.

As the number of people increase, someone will always be left out, so "training" must occur to teach the new words and the new meanings for old words. New procedures must be explained or shown by example. The rate of communications change either slows down or the population becomes fragmented and misunderstandings occur more and more frequently. The problem becomes even more evident as groups (tribes) separate from one another. Now, the cross-training effectively ceases and the "language drift" between groups increases.

Eventually, disparate groups must reestablish communications. Whose new words will be accepted? Whose new meanings for old words will become the accepted definitions? What if the drift has gone on so long that some of the words are thought to have the same meaning, but are subtly different? This is the state of things today.

Process and Procedural Standards
Now that a group could talk about something, capturing and passing on how to do things became not only possible, but imperative. From how to start a fire or make an atlatl, to how to design the software for a Martian rover, we need to be able to tell others what we have learned and how to do things without them having to discover it on their own. Thus are born both Process and Procedural Standards.

Procedural standards are more tailored to being able to "build" specific existing "products," whereas Process standards are more along the lines of how to derive and build things that have never existed before.For example, there are Process standards that describe how to create new Procedural standards. Neither of these standard types are intended to be cookbooks. It is not uncommon for these types to be merged for "practical" purposes.

At this level, things start to get left out, often deliberately, as too much "unnecessary" detail prevents people from understanding things. There is a reason that Managers only want 1-2 page bullet summaries instead of detailed reports (and yes, I know I am violating that in this article) - they can retain only so much, so it is important to keep it simple.

What this means is that we have to assume a common language and skill set. If either of these lags behind our assumptions, there will be misunderstanding and failures will result. This is one of the major reasons there is no "One Standard to Rule Them All." Every audience comes to the table with different set of backgrounds, skills and biases. Each "standard" is trying to solve a specific set of problems for a specific audience. Expressed another way, this is why we cannot use the same language to describe SCM to a set of realtors as we can to rocket scientists.

Standards Bodies
Over the years, we have gone to great time, trouble and expense to create Standards Bodies whose sole purposes is to document concepts, processes and procedures that reflect the "best" we have learned, or that we think would be a "really good idea." Many (most) of the standards that these bodies produce are intended to be as explicit and unambiguous as possible. They also tend to be targeted towards either larger organizations that can afford the overhead of compliance, or toward products whose development is regulated. And as we all know, every one of these organizations agrees 100% between them - Not!

SCM - Where Do We Stand?
So where do we stand from a CM standpoint? First, are we talking about software CM, hardware CM, systems CM (ITIL) or some other variant of CM? For simplicity's sake, let's assume we are talking about Software CM. Now, are we going to limit this to just Version Control (VC) and Defect/Issue/Enhancement Tracking (DIET), or are we also going to include Build Management? How about Release Management? Are we going to have to also cover any or all of Requirements Management? When in the Software Development Life Cycle (SDLC) are we going to start participating? At which point do we need to become involved in the planning process? It turns out that different standards require SCM participation at different points and levels in the SDLC - and it is beyond the scope of this article to provide either a description of each of the standards or to compare them.

So it only makes sense to isolate SCM from the other areas and describe its policies, principles, processes and procedures in isolation. Something we, for want of a better term, call an SCM Plan. And the various Standards Bodies must agree, because they have individual standards that do nothing other than cover the SCMP's creation, content and use.

Phooey!

SCM is tightly integrated with Management, Development and Quality. Isolating it from them makes it seem that less integrated than it should be and duplicates much of a project's boilerplate material unnecessarily. Most standards that are SCM-specific are targeted toward the creation of SCM Plans. The plans in turn are used to document roles and responsibilities, which items are to be controlled, the control mechanism (along with when they should first be placed under control, how they are to be changed and what to do with them when they become obsolete), how and when derived items (deliverables) are to be produced, naming conventions (including directory, file, variable, release and anything else that can be crammed in) and, in many plan specifications, the project schedule itself. What this tends to produce is a massive document that few read and even fewer understand. Depending on regulatory and/or contractual requirements, an SCM Plan may even take on a legal or quasi-legal standing - without the benefit of having internal legal oversight.

The other SCM standards are more along the line of guidelines or frameworks that try to specify SCM "best practices." While there are many good practices, they tend to vary greatly in the details depending on the tool chains and development methodology in use. They are either too vague to be of any practical use or so strict that they are rarely usable.

What I have found to be more reasonable from a practical standpoint is to have a master project plan document that describes the information contained in the typical SCM Plan along with the development methodology, project planning information and anything else that makes sense. The use of fence charts, color coding, indexes and other documentation tricks can make this both useful and usable; especially if it is hyperlinked and has collapsible section levels.

Summary
Even though I have presented the rationale for standards from a non-traditional viewpoint, I think that the roots for all standards can be traced to a combination of human nature and linguistic evolution. Reinventing the wheel may or may not be a good idea; it depends on whether the new wheel is better than the old one. Reinventing the wheel just because one has to derive how to do so from scratch - that is a problem.

Do I think standards are a good thing? Yes! Even if I did not believe that standards are a good thing, human nature being what it is they would still be created and used. If for no other reason, standards provide a benefit to organizations and industries where ever changing group dynamics and turnover are prevalent. Do I think every standard is applicable? No! As I stated earlier, each standard is created to solve a particular problem or set of problems and has a specific audience in mind. Go outside of this zone and you risk causing more problems than you solve.

Know what you are trying to solve by first determining the root problems and your culture, then try to either find a standard that matches or one that can be modified to fit your situation. Just make sure that if you follow a standard, you truly follow it and that if you modify a standard that you document where you vary from it. This will help reduce confusion when new people come into contact with it.