Identify Valid Standards

I can’t tell you how many times I’ve been in software planning meetings when an engineer addressed the team and claimed that we should use {insert technology here} because it’s the “Industry Standard.” I also can’t tell you how many times I’ve done the same thing. I’ve gone into my boss’s office and claimed that we should use a particular stack or technology because it’s an “industry standard.”

This reasoning is attractive because on the surface it seems valid. I mean, it must be an industry standard for a reason. Right? We’d be silly not to use it as well. Doesn’t that make sense?

Hype mentality

“Hey coach, I think we should run screens because it’s the league standard. Everyone runs screens. If we want our team to win, we need to be running screens all the time."

Choosing technology based on popularity is easy. As programmers, it’s important to us to stay current and not let any good technology get past us. As a result, there are many ways that we can be influenced; industry publications, surveys, Blogs, Twitter, Reddit, even chatter in the break room. However, we need to be careful to weigh arguments based on technical merit and not succumb to the subliminal effects of hype.

Hair-on-fire mentality

“Hey coach, I think we should stop using back-shoulder passes down the field. We should remove them from our playbook entirely. Last time we ran a back-shoulder pass, we went three and out."

When bugs that appear in staging (or even worse—production) people will look for a root cause for why it occurred. This is good to do and it’s definitely the correct response. But those investigating should be sure to focus on the root cause of the bug. If they find a bug in code that relies on a third party library, there is a temptation to question the decisions of the team that added the library. This is usually due to a misplaced concern that the bug is a result of using a less popular (or non-standard) library. Instead, the investigation should focus on things like logic errors, syntax errors, and whether behavior is unit tested.

Sweeping rules dictating which libraries engineering teams must use are not the answer. Such a reaction result in standards that halt progress, stifle problem solving, and impede innovation.

How standards help

When programming systems, standards should exist around the parts that need ‘glue’. Anytime there are two applications that need to talk to each other, they should follow a contract to ease communication between them. Examples of these kinds of standards include specifications for protocols such as HTTP, SAML, and OAuth.

Another area that benefits from industry standards is when describing languages. There must be a standard for what an <h1> represents in HTML, and for how a CSS rule such as h1 { color: red; } affects it. I wouldn’t be very productive in a language if when I wrote string it would treat it like a float. So having a language standard that defines the expected behavior of syntax and types is very helpful.

The key to these standards is that they are defining expected behavior for a given tool. These standards do not dictate which tool to use.

Picking the right tool for a job

Some may claim that one software framework or language is an “industry standard”. Often, this is a result of the person seeing it used by others or featured in articles. So, they conclude that they should use it on every project. If there is even a vague similarity between their current project and the tool’s stated goals, then some people assume they’ve found the best tool for their job. More should be considered when choosing tools.

Good reasons to use a tool:

1. It is stable
2. It does what we need
3. It is well supported
4. Ease of use
5. Compatible with existing system

Bad reasons to use a tool:

1. It’s popular
2. It’s new
3. It’s been trending on Blogs and industry news sources.
4. The current tool is boring. We could use a change.

Don’t flippantly swing the “Industry Standard” club

Promoting a tool by claiming that it’s an industry standard, rather than because it adheres to standards, is a mistake. There is a key difference between adhering to standards and being a standard. Industry standards are most effective when describing protocols and language behavior. We should select our tools based on how well they adhere to standards.