Mottos and Catchphrases

It is natural that over the course of a career one encounters pithy remarks and advice and rules from various mentors and coworkers. Here are a few of the pearls of wisdom that have proven so recurring or useful that they’ve earned names of their own:

The Nimmer-Beyoncé Rule: If you liked it you should have put a test on it.

Credit to Jeremy Nimmer, who adapted and taught this rule from Google’s Abseil.

Code that lacks tests will rot, fail, and eventually be deleted; this is the natural course of things, the circle of life. As an author: Could someone wreck or delete your code without causing a test failure? If so, you must not have liked it very much, did you?

This is in a sense the most widely violated rule imaginable. It is in another sense impossible to violate: If you lack the determination, skill, foresight, or strength of character to put a test on it, isn’t that a correct assessment of your ability to maturely love your own code?

Rico’s Law of Scripting: Use scripting languages for scripting.

Credit to Rick “Rico” Poyner.

An inescapable rule of inversion-of-control architecture is that control-like configuration will grow into a scripting language. Pretty soon your tidy little yaml or toml or even environment variable rig is learning variable substitution, and looping, and inclusion, and indirection…

This is why so many yaml variants add math and pathing operations (see, e.g., hydraconf or omegaconf): They are growing up into scripting languages.

But a defining part of programming languages is that they are complex and subtle and not written by accident. If your configuration language is growing into a scripting language, it’s time to do the (often very difficult) work to replace it with an actual interpreter.

The ultimate expression of inversion-of-control is to turn your binary with a config language into a bound library that is called from another language.

The ultimate heroically epic failure at this principle is the Bazel build system, which contains a nearly complete re-implementation of Python (“Starlark”).

Gould’s Law: If it confuses, it is confusing.

I said this enough times that people put my name on it.

If your code conventions say that confusing comments or documentation are a defect (and they should!) then anyone being confused by the comments or docs is irrefutable proof of defectiveness.

As a corollary, resolving confusion in issue or PR discussions is never correct, because it doesn’t change the text that caused the confusion. The fix must always be to the text, not to the reviewer’s understanding.

Spiro’s Principle: There is a knife in your code’s back.

Credit to Spiro Michaylov.

We do not write “monuments more lasting than bronze,” we write software; it has a beginning, a middle, and an end, and some day someone will use your code for the last time. It will be sooner than you think.

So while we write software of the utmost quality at all times, we do not necessarily need to fix every architectural hiccup every time. Your code is likely to be deleted long before every last deficiency in it is plumbed.

Leave feature gaps. It’s fine. Better a feature gap than a pile of premature functionality that must be maintained for a decade and discarded barely-used.

Relatedly, Edsger Djikstra is credited with the aphorism that “every line of code is a liability” and James Shore argued compellingly that the correct measure of technical debt is simply “lines of code”.