Self-destructing standards

By Andrew Clifford

Many standards suffer from creeping self-destruction. Should we do away with them?

There seems to be a common progression to the creation, elaboration and abandonment of standards. It goes something like this:

• Step 1. Someone has a good idea about how to do things differently.
• Step 2. Because the idea works well, they write it down for other people to use.
• Step 3. People think it such a good idea, they adopt it as a standard.
• Step 4. To make sure the standard delivers maximum value, it is made more comprehensive and more formal. An industry consortium or government body takes over the standard.
• Step 5. Because it is comprehensive and formal and official, people really believe in the standard, and demand it as basis for all work, even areas outside the scope of the original good idea.
• Step 6. An industry grows up around the standard, with tools, and training, and certification. People's jobs depend on the standard, and it is defended rigorously, and developed further and further.
• Step 7. The tools, training and certification take over; they become the standard; the original good idea is lost.
• Step 8. The standard is seen as bureaucratic and unhelpful, or just too hard.
• Step 9. Someone has a good idea about how to do things differently.

IT is particularly prone to this sort of self-destructive standardisation because people in IT are attracted to both making things systematic and making things efficient. The movement to agile methods is in part a reaction to the earlier structured methods, and yet we can not seem to resist adding formality which will eventually sink agile methods.

You can even see this happening with technical standards. XML is basically a simple standard for encoding data. People elaborate XML, with schemas, name spaces, SOAP wrappers, and things like that. In response, people adopt other standards, such as JavaScript Object Notation (JSON) structures, taking them back to something as simple as basic XML.

Although there are exceptions, where standardisation is both necessary and necessarily complex (such as HTML standards), there does seem to be a limit the sophistication and complexity of a standard before you get a counter-movement to something simpler.

I do not think we should get rid of standards, but we do need to avoid the problem of over-elaboration and abandonment. I suggest:

• If you have a good idea, try to distil and promote the fundamentals of the idea. Wrapping it up in a formal standard may smother it.
• Before you insist on a standard, ask yourself whether you really need the standard, or just the good ideas that it contains. If you insist on a standard, you might be institutionalising all sorts of baggage that you don't really want, and missing out on the fundamentals.
• Be suspicious of any standard where the specification runs into hundreds of pages, and where there are special tools and certification schemes. It will be hard work, and may be getting to the end of its life.
• Fundamentals are important. Standards can provide a good focus for the work, but they do not replace the underlying ideas and skills.

Subscription