A Meditation on Standards
When I started middle school (not recently), it was the first time I had different teachers for every subject. Before then, I had one way to format my name and details on my papers, one set of rules, and so on. I was surprised to find that each teacher had a slightly different set of standards for how we should format our work, the class rules, and what they were expecting.
At the time, my response was “I better learn what each one wants and figure them out as people so I can please them,” which probably says a lot about my state of mind at the time. My opinion now is that the school didn’t have sufficient centralized standards. Certain elements in fact should have been consistent from classroom to classroom, with a minority of items specific to the individual teacher, rather than each class feeling so different from one another.
This scenario ended up teaching a different lesson than was likely intended. Each individual teacher thought they were teaching “learn to follow instructions and conform to standards,” when the lesson was in fact “how to manage up when you have multiple bosses who disagree with each other” and “keep track of competing standards and the scenarios in which you should use each of them.” There are several things we can take from this.
EVERYONE THINKS THEIR STANDARDS ARE *THE* STANDARDS
It’s easy to have a myopic view when one is only aware of a single set of standards, or personally designed those standards. Getting past this requires taking the time to learn from others outside of your immediate classroom/company/field/geography, as the case may be.
Without a central authority on standards (which comes with its own benefits and drawbacks), standards proliferate and no one knows just how many there are, except perhaps the unfortunate end user navigating multiple models simultaneously.
Historically in most fields, multiple standards and models arose over time, and a single version won out. This is sometimes due to good timing, funding, influence (proportion of membership in standards organizations), and other factors. We tend to take for granted that the standards we learn are *the* standards, but they are likely to change over time as the original reasons for their creation will one day no longer match with reality. As with the maxim “history is written by the winners,” there may be some truth to “standards are written by the winners.”
Additionally, some standards are simply models (i.e. necessary simplifications and arbitrary buckets), and models cannot be mistaken for what they represent. Which is more “true” – the application layer is a single layer or should be split out into the application, presentation, and session layer? Both and neither. It’s a model. The same set of processes happen, but they are bucketed differently.
SOME THINGS LEND THEMSELVES BETTER THAN OTHERS TO STRICT STANDARDIZATION
As a general rule, the more closely the standards relate to a physical object, the stricter they are. For electronic devices to work, and to work with each other, there must be clear structure that is followed exactly. For safety-critical fields like medicine and aviation where human life is at stake, the Checklist Manifesto mentality reigns supreme.
Get further away from physical objects and life-or-death situations, and you’ll find the standards vary and/or do not exist. It’s easy to play faster and looser with software than it is with hardware. “Well, does it run?” The way developer A writes can be entirely different stylistically from developer B, and that’s not a problem until they both leave and developer C has to make sense of everything that’s duct taped together.
While the freedom of creating something outside of the constraints imposed by standards can be exhilarating, it may cause significant technical debt down the line, which is much more intangible than “the device does not turn on” or worse, “the device explodes” (i.e. the result of creating electronic devices without standards).
This does not mean that there shouldn’t be standards for other fields, just that the consequences of not having them are less immediately felt and often ignored. There are many companies working to enforce enterprise standards of data, taxonomy, process, and more, but to get buy-in, there has to be enough pain to feel the need for major change.
Additionally, because these fields operate more loosely, there are often multiple “right ways to do it,” and even (especially) the most experienced people will argue with what the ideal way should be. There is not always a clear answer other than “pick one”, but the impetus to narrow the options doesn’t exist in the same way as it must with hardware.
THERE WILL ALWAYS BE COMPETING SYSTEMS
Unless the world operates under only one company (a bad idea for a multitude of reasons), there will always be groups that create standards in isolation from each other, groups that improve on existing work, and more. We can’t and shouldn’t wish for singular answers to every problem.
So, where does that leave us? With multiple systems. There is some ideal balance between fostering competition by not having a standard solely owned by one large company but also not producing a situation where an individual in a given field has to deal with an insurmountable number of differences that add unnecessary switching costs (i.e. changing the focus of their attention, flipping between mental models) to the job that they do.
STANDARDS DON’T ALWAYS SAVE TIME
They make things work and make them repeatable, but add a decision point about which standard(s) apply.
It would seem that a benefit of having standards is reducing the number of decisions that need to be made. You have a pre-built if/then playbook, so naturally that saves time and energy, right?
Not necessarily, because of the point above. We will never live in a world of one standard that applies to all scenarios, and there will always be exceptions to be had.
Instead of operating unconsciously (without standards), we now must ask before each task, “Which standards apply?” This actually *adds* mental overhead. This is not automatically a bad thing, as it allows for interoperability and future understanding by others, but we should not pretend that all standards reduce mental load.
STANDARDS ARE A GIFT/CURSE TO FUTURE GENERATIONS
In a field with fewer standards, when you ask the question, “Why did John write it this way?”, you often have to ask John (who left the company 5 years ago), his friend (rarely responds), or pore over his past writing.
In a field with more standards, the answer is more often “Oh, back on that version, the syntax was different (link to docs).” Now, historical manuals and documentation are absolutely not perfectly preserved, but there is often something more substantial to point to than one individual’s thoughts from many years ago. The answer may be “talk to John, he knows the old system,” but the old system probably had at least some overarching structure, and even if the docs are in an archive of an archive, they likely exist.
THE STANDARDS LEARNING CURVE
We often start our journey with a sense of reverence for the standards, as if they were handed down from the Standards Gods on High. Sadly, they do not exist, but we’ll get to that. This is not an incorrect way to start, but it is only a starting place. We must first learn the standards as if they are fact to get hands-on experience. We then learn when to change them – “they weren’t true all along?” Finally, we internalize them enough to understand the original thinking that created them and when it does and does not make sense to diverge from it.
Initially, no one imagines themselves in the position of creating standards when first learning, so they seem immutable and monolithic. If we continue on the path of mastery, eventually we realize that we arrive at the level of the standards-makers. This brings us to the next and final point.
RULES ARE CREATED AND MODIFIED BY HUMANS
They’re not always right and they’re changeable.
There is no single source of truth from which all rules emerge and are validated against. Rules are made by people, and people are fallible and products of their time. Future people and times may come along that necessitate changing the rules. We should not live at the mercy of the rules, nor should we change them without understanding why they were created. I frequently reference Chesterton’s Fence. It’s tempting to want to re-create the traditional order once you reach a level of understanding how arbitrary some of it is, but it’s often that things are in place for reasons that require more digging. We should not be so self-assured that we could do better (create a better system/model/rule set) without testing this assumption.
In the end, we are responsible for what we do with what we’re given, and finding the balance of when to lead with change and when to follow existing convention is the work of a lifetime.