I rediscovered this beautiful text about standards and found it very applicable to my own work in safety management:

"What's so bad about not following standards, when most of them are so bad it would be a disaster if we used them?

If the standards are bad, it's certainly better not to follow them. But wouldn't it be even better to get rid of them or to replace them with meaningful, useful standards? One way to do this is to undertake a review or reviews of the existing standards. (...)

Assuming there may be one or two good standards (possibly by accident) among the hundreds, how can you know, without reviews, whether or not they're being followed? There's no sense railing against a bad standard that everyone is ignoring or basking in self-congratulation for good standards that are receiving the same treatment.

What should we look for in reviewing standards? (...)
1. Contradictory standards;
2. Ancient standards carried forward cumulatively from old systems no longer in use;
3. Standards resulting from political decisions by the old regime no longer in power;
4. Standards defined to incredible levels of nit-picking applied simultaneously with standards that are so broad as to be uninterpretable in a consistent way;
5. Arbitrary choices elevated to the level of gospel;
6. References to documents that no longer exist;
7. Standards applicable for a limited time, but with no date;
8. Rules that, according to their preconditions, could *never* be applied;
9. Explanations that make a seemingly clear standards obscure; and
10. Examples that don't apply to the standard under discussion.

(...) the standards organization doesn't function in a vacuum - or shouldn't, if it does. Standards writers must know what the actual producers are doing and not doing, which is one reason we recommend having someone from the standards group represented on at least some review committees.

By participating in reviews, the standards group can base their standards on what programmers are actually doing; rather than on what someone at a very high level thinks they are doing.
Conversely, there should be plain-dirt programmers present in any reviews conducted by the standards group of their own material, to inform standards how their decisions will affect the programming process.

As a by-product - or main product, if you like to think of it that way - the programmers may learn about the standards more quickly and more effectively than by waiting to read the nine-inch manual."

Source:
Freedman, Daniel P., Weinberg, Gerald M. (1990), Handbook of Walkthroughs, Inspections and Technical Reviews - Evaluating Programs, Projects, and Products, Third Edition, New York: Dorset House.

Picture by Dall-E