All Code Is Not Equal: On Research and Production Code
Post from July 16, 2014 (↻ May 18, 2018), filed under Web Development.
This and many other posts are also available as a pretty, well-behaved e-book: 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).
For some reason, our insight has much stopped here. (Please note that I tend to use generalizations for emphasis, so understand exceptions to prove the rule.)
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.
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 is used by individuals and confined groups. Examples range from prototypes for commercial websites to test suites for technical standards to plain trial and error.
The purpose of production code is live deployment and use. It, ideally, is 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 is also less relevant because issues in the amateur context have a much smaller radius and impact.
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 an antagonist). 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).
The hypothesis is that there’s not just a difference in code (research and production), but that, unchecked, mixing types of code can lower the quality of production output. The following HTML and CSS examples may be able to support the hypothesis.
One can argue that reset style sheets, something that originated in the W3C community, are an example for 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.)
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 have gone straight into any code base.
The so far widest-spread confusion in terms of selector performance with its resulting near-dogmatic ban of the universal selector stemmed from 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 them for their harm. I contend that there are many more cases in which lack of distinction and mindless copying led to other, well more severe issues. (Please check any disagreement on whether it applies to the idea or an example.)
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 sufficiently 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 is naïve 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 even more so 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 the Author
Jens Oliver Meiert is a technical lead and author (sum.cumo, W3C, O’Reilly). He loves trying things, including in the realms of philosophy, art, and adventure. Here on meiert.com he shares and generalizes and exaggerates some of his thoughts and experiences.
If you have any thoughts or questions (or recommendations) about what he writes, leave a comment or a message.
Have a look at the most popular posts, possibly including:
Perhaps my most relevant book: CSS Optimization Basics (2018). Writing CSS is a craft. As craftspeople we strive to write high quality CSS. In CSS Optimization Basics I lay out the, at least some of the most important aspects of such CSS.
Looking for a way to comment? Comments have been disabled, unfortunately.