The Psychology of Quality and More

C Style: Standards and Guidelines (contents)

CHAPTER 11 : Implementing Standards

PART 5 : IMPLEMENTATION

CHAPTER 11 : Implementing Standards
11.1 Raising awareness of the need for standards
11.2 'Disadvantages' of coding standards
11.3 Getting the standards defined
11.4 What should the standards contain?
11.5 Getting the standards into use
11.6 Prove the value
11.7 Keeping the standards alive
11.8 Making sure the standards are used
11.9 Summary

<--Prev page | Next page -->

11.3  Getting the standards defined

The next step is to ask for help in defining the standards. Here is where the excuses will start - most people will just be 'too busy at the moment'. This is not necessarily a bad thing. If too many people get involved with the basic definition, then the standards will either contain a mixture of everyone's pet likes or else there will be little agreement and precious few standards will get defined.

A good arrangement is for one person (you?) to do the actual donkey work of collecting opinions and ideas and shuffling them into some semblance of order. This initial document is then knocked further into shape by a small committee of about five people. These people must be recognized and respected by all other users as being able to represent them. Preferably, each affected group should be represented on this committee.

A hint: Don't use the word 'committee'. Use 'task force' instead. It sounds less bureaucratic and better indicates the objective of the group, which to complete a given task, rather than to endlessly discuss ever more abstract points of syntax.

It is also a good idea to have a visible schedule. This emphasizes the urgency of the task and ensures that it does not dribble on ad infinitum. Of course, it is still possible to slip the schedule, but this should not be done without due consideration of the effect on the credibility of those concerned.

When the task force members have come to an agreement, the first full draft of the standards should be reviewed by all (or a representative sample of) potential users. The task force can then discuss the comments and revise the document. The process may be repeated, but only a very few times. It is very important to maintain credibility.

As a rule of thumb: if more than a few people have strong objections to any the proposed standards, then it may be better to make them guidelines, or require the individual teams to define their own variation, rather than run the risk of the standards 'falling into abuse, disuse and disrepute'. As an example, you may demand a bracing layout ( {...} ) standard be defined within each team, without imposing a company-wide standard.