All Code Is Not Equal: On Research and Production Code
Published on JulĀ 16, 2014 (updated FebĀ 5, 2024), filed under development, quality (feed). (Share this on Mastodon orĀ Bluesky?)
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 web developer, manager, and author. Iāve been working as a technical lead and engineering manager for companies youāve never heard of and companies you use every day, Iām an occasional contributor to web standards (like HTML, CSS, WCAG), 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. (I value you being critical, interpreting charitably, and giving feedback.)