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.
Looking back on my newsletter, I do a LOT of articulation. Here are a few of them:
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:
That’s all I have to say about articulation for now. Have a great week!
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.