All Code Is Not Equal: On Research and Production Code
Post from July 16, 2014 (↻ June 9, 2021), filed under Web Development (feed).
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).
For some reason, our insight has much stopped here. (I tend to generalize and exaggerate for emphasis.)
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’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.
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).
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.)
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.
I’m Jens, and I’m an engineering lead and author. I’ve worked as a technical lead for Google, I’m close to W3C and WHATWG, and I write and review books for O’Reilly. I love trying things, sometimes including philosophy, art, and adventure. Here on meiert.com I share some of my views and experiences.
If you have a question or suggestion about what I write, please leave a comment (if available) or a message. Thank you!
Maybe this is interesting to you, too:
- Next: On Web Documents and Web Apps
- Previous: The Law of Travel
- More under Web Development, or from 2014
- Most popular posts
Looking for a way to comment? Comments have been disabled, unfortunately.
Get a good look at web development? Try The Web Development Glossary (2020). With explanations and definitions for literally thousands of terms from Web Development and related fields, building on Wikipedia as well as the MDN Web Docs. Available at Apple Books, Kobo, Google Play Books, and Leanpub.