on the importance Of standards

Not everyone has them in every field of their life (yes, that friend of yours with her choice of men is a fine example), but when it comes to software that doesn’t mean standards are any less important than that coding style you are slaving to keep, or the 400% test coverage you boast about so much.

By World war II the shipping industry was in trouble. The reliability was poor, packaging was tailor-made for each shipment, and loading and offloading were dangerous, slow and labor intensive. The airplane was a faster alternative, but had problems handling volumes and was (as it is today) quite expensive.

And then came the shipping container, with its specific width and height, featuring different sizes (full, half, and quarter, of course). Specifications came as far as noting where the doors will be placed, what kind of handles will they have and how they will open. Even the type and size of the bolts that will be used was specified, along with where the bolt holes will be placed on the container to lock it into place in the ship and to each other (that’s more important than you might think).

So now we have the STANDARD (intermodal) shipping container – and every shipment should be loaded into this specialized box which is a bit of a headache but has it’s pros. The standard means we can standardize the ships, with suitable decks and connecting points (remember those bolt holes?); by stacking the containers we can build fewer decks, lowering the cost of every ship and increasing it’s load (remember those bolt holes?). That also means we can standardize loading and offloading of the ship – with cranes, trucks and even trains adapted for the standard (and once again, these bolt holes come to mind).

The containers can be stacked on shore as well, and since the standard says they should be weatherproof there is no need to build and maintain specialized storage facilities, making extending the harbor capacity that much simpler. All of these new abilities are more than enough to cancel out any complaint regarding the overhead of loading a container with goods – the shipments now move faster through the system, arriving better protected and with greater accuracy, and with smaller price tags. Some may even say those containers are beautiful to look at.

As the introduction in the gang of four’s Design Patterns notes – the greatness of a design is truly seen not when it performs perfectly where and when it was intended to, but when it exceeds expectation, and is used by people for which it was never created to achieve goals it was never designed for.

Whenever you visit a friend who lives in what used to be a factory, or meet a contractor who works out of an office that used to be a container, or use a POSIX operating system, or even just code in Python or Java and use a version control, try to see where the designers of those systems decided on a standard (of any sort), what was the price and what were the payoffs (modularity, simplicity, performance, etc.)? Learn to see and think in standards and greater goods and try to incorporate these ideas into the system you build, Your future self will thank you.


09/08/2015  edit: First I would like to thank to Olga B. for the text review, but just as important to the completeness of this post was a comment of a dear friend that “The nice thing about standards is that there are so many of them to choose from.” He is 100% correct. We often find ourselves refusing to use existing standards for various reasons (some more legitimate than others). I believe most of the problems we will encounter in our lifetime as engineers were encountered before, in some form or another by someone else. All we have to do is to be humble enough to recognize that his solution is applicable to our problem and embrace it as our own.

It’s worth mentioning that the reason we have so many standards is that in software engineering it is as simple (if not simpler) to create a new “standard” of our own instead of using someone else’s. Python, with it’s ample importable libraries makes using existing standards more appalling, but you didn’t hear me saying anything nice about a language where white-space can break your code. Here, as before, we must get over ourselves and “use before code”, this not only spares us from unneeded coding, it also enables us to blame someone else case something fails.

Adam Lev-Libfeld

A long distance runner, a software architect, an HPC nerd (order may change).

Latest posts by Adam Lev-Libfeld (see all)

on the importance Of standards

Leave a Reply

Your email address will not be published. Required fields are marked *