All Code Is Not Equal: On Research and Production Code

Published on July 16, 2014 (↻ February 5, 2024), filed under Development (RSS feed for all categories).

This and many other posts are also available as a pretty, well-behaved ebook: On Web Development.

Web development is at a point at which we need to make more fundamental distinctions. One of them is a more determined one between web documents and web apps (I’ll share my thoughts separately), another one is between research and production code (which I’ll discuss here).

The distinction we naturally make is one between code in each language: C code, Java code, Python code, JavaScript code, HTML code, CSS code, &c. That distinction makes sense: You can’t learn or work with any programming, scripting, document, or formatting language if you can’t tell it apart.

For some reason, our insight has much stopped here. (I tend to generalize and exaggerate for emphasis.)

A Difference

The first point I like to make is that in any language, there are roughly two types of code. As you noticed, I like to call one type research and the other one production code. All code appears to fall into either category. [For clarification, unoptimized, uncompressed development code is ignored here, that is, it’s taken to reflect either research or production purposes, too.]

The primary difference between the two types of code is purpose. Secondary differences, in consequence, are quality and audience.

The purpose of research code is experimentation, testing, and delivering proof of concept. It may be of low quality, and can be uncomfortably unstable and non-interoperable. It’s used by individuals and confined groups. Examples range from test suites for technical standards to prototypes for commercial websites to plain trial and error.

The purpose of production code is live deployment and use. Ideally it’s of high quality, robust, maintainable, and scalable. It’s usually serving end users. Examples include much of what carries an expectation to work reliably, most notably commercial services but well including personal websites.

There is another major distinction one can make between types of code, namely context (personal/amateur and industrial/professional). I don’t deem this distinction decisive because it appears to translate into a difference of complexity rather than one of quality. It’s also less relevant because issues in the amateur context have a much smaller radius and impact.

A Problem

As long as code is isolated and stationary, there are few complaints. The reality, however, is that code lives, gets added and removed, gets copied and modified. It’s lent and borrowed liberally. Code is “social,” so to speak. It likes to mingle.

And thus, with its different purpose, lower quality standards, and lesser stability, research code is easily negatively impacting production code it comes in touch with. Trouble is likely to arise when we treat it like any code, and blend it without awareness, modification, and supervision.

The trouble is not mutual, for only production code, and that all too readily, gets disturbed by research code. Research code rarely has to fear production code.

The purported lowering in quality can take several forms. Research code can outright break production code (this is the least worrisome variety, ironically, because it identifies itself immediately as antagonistic). It can go counter some of the higher standards for production code, that is, reduce its quality and impair its stability, maintainability, or scalability. It can turn into a “sleeper” and only have an effect later (the most problematic character).

Some Clues

The hypothesis is that there’s not just a difference in code (research and production), but that, unchecked, mixing types of code lowers the quality of production output. The following HTML and CSS examples may support the hypothesis.

One can argue that reset style sheets, something that originated in the W3C community, are an example of research work, work that shouldn’t have made it into production. (And so Eric Meyer himself suggested caution and modification, but people took code for code and ran with it.)

Conditional Comments, if one’s nice, can be regarded as a not thought-through experiment, one that was never fit to make it to live websites either.

Much of the markup of the HTML 5 Boilerplate initiative, promoted by Google Developer Relations staff (who don’t work on Google production code), is also “research-y” and shouldn’t go straight into a code base.

The widespread confusion in terms of selector performance with its resulting near-dogmatic ban of the universal selector stemmed from a lack of distinction.

“No script” styling cruft, that is, permanently added but mostly out of place code like class=no-js, comes also out of a theoretical context and mean another case for research work causing problems in production.

These are examples that come to my mind readily because I had already criticized these in the past. I contend that there are many more cases in which lack of distinction and mindless copying have led to other, well more severe issues. (Please check disagreement on whether it applies to the idea or an example.)

Some Awareness

The primary goal of this article is to create awareness. All code is not equal, as the heading suggests, and I will assume that the first section has explained why this is the case beyond different languages.

As research code is minority code and not always harmful I don’t see a need for a more drastic differentiation. (Former revisions of this article suggested to also separate research from production coders, but I’m not sure anymore that’s necessary.) But differentiation we need; it’s naive to close the eyes to the fact that code has different purposes, different quality standards, and different audiences. In classical Jens manner I’m tempted to call non-differentiation irresponsible.

The distinction appears to explain some of the issues (and confusion) our industry has faced and with that encourages to stop committing the same mistakes. Production code has higher standards than research code, and so it should look at research to be informed, but not to be patronized. Blindly copying code has just become unintelligent for another strong reason.

About Me

I’m Jens (long: Jens Oliver Meiert), and I’m a frontend engineering leader and tech author/publisher. I’ve worked as a technical lead for companies like Google and as an engineering manager for companies like Miro, I’m a contributor to several web standards, and I write and review books for O’Reilly and Frontend Dogma.

I love trying things, not only in web development (and engineering management), but also in other areas like philosophy. Here on meiert.com I share some of my experiences and views. (Please be critical, interpret charitably, and give feedback.)