Driving down a shady road, windows down, listening to the frogs and crickets, my family was in the car talking about various stuff and things. This summer evening we happened to talk about the invention and emergence of the word “yeet.” I observed that it was kind of cool to have a word with a known origin and etymology, even if that was only because it was a made-up word. My daughter instantly responded that “all words were made up by someone.”

What could I say? Of course it’s true!

I’ve previously talked about the difficulty that words present. In 2015 I discussed the perils of semantic coupling that could emerge when we get fooled by nouns. The existence of a noun makes us think we understand a concept. Once we try to define a predicate to answer “Is X an instance of Y?” for any noun Y it becomes difficult, verging on impossible, to find a categorical statement. Instead we fall back to the Potter Stewart method.

In Wittgenstein and Design (say that three times fast) I talked about pursuing adjectives instead of nouns as a way to carve a design space.

Today, I want to talk about how we use words as signifiers for their semiotic content. In particular, the words “manual” and “automated.”

Two-legs good, four-legs bad

We are now ten years into the DevOps era. Among both practitioners and adopters, there is a tendency to use “automated” as a pseudo-synonym (psynonym?) for “good” while “manual” stands in for “bad.” The trouble is that the closer you look the harder it gets to tell whether any particular thing is manual or automated!

Suppose we are in an incident. I invoke the “break glass” process to ssh into a server to run a bash script. Was that manual or automated? Well, both, sort of.

Out of the Morass

Instead of applying a blanket statement like “manual” or “automated”, we should look more closely. Specifically, what actions are being executed by which people or systems via which tools in response to which stimuli.

When we engage with detail at that level we can begin to ask and answer more useful questions than “is it automated”. For example:

Breaking the question down this way won’t help us answer whether something is “automated” or “manual.” But it will help us answer how likely the process is to deliver availability, stability, security; or conversely, how likely it is to amplify noise, create oscillation, or induce drag.