Why should I care about software standards?

From time to time I am pleased to receive submissions from colleagues, who can give different perspectives on embedded software. This week, Carlos O’Donell is talking about software standards and why we should all care about them …

My name is Carlos O’Donell and I work for Mentor Embedded as part of the Sourcery CodeBench team, in addition to that I volunteer my time as a GNU C Library developer. In both of these roles I look at a software standard at least once a day and some days more. Let’s talk about software standards and if you stick around and comment maybe I’ll make this a recurring blog.

Standards can be long, or short; difficult to read, or simple to understand. They share one thing in common: a desire to guide you towards achieving a goal in a repeatable fashion. A technical standard is a dull thing to most people; personally I find them fascinating. Standards are a reflection of the deep knowledge of technical experts influenced by the time and place of their creation. Let me give you an example which will lead straight into why standards matter.

In 1904 the Great Baltimore Fire destroyed 1,500 buildings and consumed over 140 acres of the city of Baltimore (Maryland, USA). In the aftermath of the fire it became clear that because the surrounding municipalities all used different hose couplings none of the supporting fire trucks could connect to Baltimore’s hydrants. The fire engines from the nearby cities of Philadelphia, Washington, and New York City could have done more had their hose couplings been compatible. The fire was one of the driving forces behind the hydrant and hose connection standard adopted by the National Fire Protection Agency. Fast forward 87 years to 1991 in the city of Oakland (California, USA) where a massive hillside fire destroys over 3,000 homes and sadly takes 25 lives. The fire hydrants in the city of Oakland were non-standard sizes, a fact which hampered the ability of additional fire crews to help fight the fire. After the fire all of the hydrants were replaced with those that that met the national standard, but not before an approximated $1.5 billion in damages from the fire, not to mention the loss of life. The takeaway: Standards matter and following them is a constant struggle (for a more thorough takeaway read NISTIR 7158).

Technical standards matter for many reasons, with interoperability and collaboration consistently ranking at the top. Interoperability between different implementations of the same standards gives you the ability to choose one vendor over another, or collaborate with friends who have chosen the other vendor’s solution. Technical standards allow educators to use them as scaffolds upon which to design training material for people desiring to enter an industry that relies directly or indirectly on the standard. Perhaps most importantly standards bring with them a stable platform of uniformity upon which innovation can thrive.

Software standards matter for all the same reasons that technical standards matter and more. In an industry whose only mantra appears to be constant change (not always good), software standards provide the guidelines for the stable building blocks we use to build complex systems. For example on any given Linux system you might be using an LSB compliant application and a core C library to communicate with the kernel, that’s ISO/IEC 23360 and ISO/IEC 9899:2011 right off the bat. Reading this web page, that’s W3C HTTP and probably W3C XML (derived from ISO 8879 i.e. SGML). Standards help power innovation. Yes there are examples where standards have gone awry, and as a proponents of software standards I’m still a little sore about the OOXML debacle, but that doesn’t change the facts on the ground. In the constantly changing maelstrom of information technology, software standards are the lighthouse by which you set a course through rocky waters.

I became involved in standards work long after I had started participating in GNU C Library development and that experience sparked my interest in standards. I encourage you to go out and do something, something that involves software, and something that interests you. After a while you’ll start to see the rough edges, where the hydrants and hoses don’t match. That’s when you should start participating in the standards process, engage the community that develops the standard, and explain your position. For international standards find the organization within your country and volunteer (in Canada that’s the SCC). Help define what it means to be a portable Linux application and volunteer to help the LSB meet their goals. No matter what you choose to do, standards matter, and they need your input!