Giving Names to Things
Naming things is hard. Naming things that have never been named is harder.
First of all, new post: Software Mimicry! It's about a thing I've seen in a lot of software tools and products that I was trying to capture in a single term, so I could share it and explore what it actually means for things. It's also a rewrite and expansion of one of my very first newsletters: on emulation.
I find myself fascinating with terms. Mimicry is something I see in a lot of different places, and I've seen people identify particular instances of it, but not connect the dots and discuss the abstract concept of mimicry. Is "articulating" mimicry into a distinct term useful? I think so! By having a term for something you can discuss it as a thing instead of being forced to gesture vaguely at it through examples.
Take, for example, "side effect". A side effect is when a function changes the outside world in addition to computing a value. Changing a global value is a side effect. Allocating or freeing memory is a side effect. Updating the cache, advancing the RNG, and making a POST request are all side effects. Side effects are generally something that increases software complexity, so are often implicitly avoided, or explicitly embedded in software constructs like monads and algebraic effects.
That all makes sense, right? But that only makes sense because I have the term "side effect". Without it, can I really convincingly explain that "generating random numbers" shares a fundamental essence with deleting a reference or logging to a file? We can vaguely wave at it and maybe point out things like idempotetncy. But it'd be a major uphill battle because people don't conceptually relate HTTP requests to playing a sound. Articulating the concept of "side effects", then, creates a new category which all these belong to, making us see them as similar. Once we see them as similar, we can elaborate those similarities / find other examples / find synonyms / all the things we do with new knowledge.
Okay, you might say, but side effects are mathematically representable, so creating the conceptual grouping is "natural". But then contrast that with something like an "antipattern". Is there a way to formalize "God objects are tempting but probably a bad thing to have"? A way that also covers Big Design Up Front and no design up front? Putting slow tests in CI/CD? But "antipattern" is still meaningful and useful. Having the word makes it easy to speak. Making the word is a meaningful improvement to our discipline.
I do this a whole bunch
Looking back on my newsletter, I do a LOT of articulation. Here are a few of them:
- Information Camouflage: When a topic is hard to search for because the search medium confuses it for an unrelated and far more popular topic with a similar name. Like "museum about zoos".
- Metafiles: Files that contain information for constructing multiple possible other files, like sequential versions in a tutorial or variations to all benchmark.
- Constructive and Predicative Data: Constructive data is everything reachable from a fixed set of rules, predicative data is a subset filtered from a larger universe.
- Rho problems: Software functions where the output isn't obviously related to the input and where errors can only affect a small set of inputs, making it very hard to test. Admittedly I hate this name, it was always a placeholder, but some other people find the term useful.
- Software-as-Artifact: A codebase that needs to be maintained as a codebase, so needs things like patterns, tests, logging, etc. The difference between programming and software development.
- Edge case poisoning: when you have to make your data model more complex to handle an edge case, like a ZIP lookup returning an array of cities because a mere handful of ZIP codes in the entire USA straddle a couple different cities.
There's a lot of terms I haven't written up yet, too. Symmetry fallacies, canonical text, interrogative examples, meatspacing, blub studies...
Naturally, some of the articulation won't take, will be nonsensical, will already have a good word, etc. Whenever I try to articulate a new word I try to look to see if someone else has already come up with a good term and use that instead, or see if the word I came up with is already in use. This happened on both ends with the Software Mimicry piece:
- "Emulation" is already in use in CS, so I renamed it mimicry
- I originally said that the opposite of mimicry is "inlining", but some people already call it "reification", so I went with that instead.
That's all I have to say about articulation for now. Have a great week!
Ad: What I Do
This has been a really good month for the newsletter! Something like a sixth of the current subscribers joined since August. I figure it's time do a quick advertisement for the work I do, since that's what pays the bills. In short, I'm a formal specification consultant.
What's that, you ask? Good question! Formal specification is a special kind of software modeling where, after you model what you're going to build, you can test the model itself for bugs. This way you can find complicated bugs in your system before you start writing any code, as opposed to after you've already written all the code, or worse, after you've already deployed all the code.
Consider, for example, a file storage service. Does your high-level design guarantee that uploaded data is eventually synced? That you don't lose data? You could try testing and code review to catch those, but what if the failure path is 35 steps long? That's what AWS discovered when they formally specified parts of their system. Smaller companies can use this, too. I first started formally specifying at a place with just ten engineers and it saved us hundreds of thousands of saved revenue a year.
Anyway, I help companies write these specifications and I teach workshops, which one client has called "the first corporate workshop they took that wasn't a waste of time. If you think this is something your company can use, feel free to send me a message! You can just email me at the same newsletter. Thank you!
(I've also done work on researching and writing tutorials for exotic technologies, which I'm pretty good at too.)
To be clear: This newsletter will always be free. There are no plans to have premium content. I am more likely to quit consulting and go back to being a full-time engineer than I am to monetize the newsletter or the blog.
If you're reading this on the web, you can subscribe here. Updates are once a week. My main website is here.
My new book, Logic for Programmers, is now in early access! Get it here.