The Unnecessary Elegance: On the Tyranny of the Idempotent Script
We are taught, from our earliest days tinkering with automation, to worship at the altar of idempotence. The doctrine is clear: a script, a playbook, a configuration tool—it must be runnable a thousand times with the same, predictable outcome. It is the bedrock of reliability, the cornerstone of modern ops. To question it is heresy. And yet, I find myself questioning it.
This isn't an argument for sloppiness. It’s an argument for context. The relentless pursuit of perfect idempotence can become a form of architectural theater, a complex performance we put on for the sake of a principle, often at the expense of clarity and simplicity. We build Rube Goldberg machines of logic—`check if exists`, `validate state`, `only then execute`—to avoid the simple, honest act of doing a thing. We contort our clean, imperative instructions into declarative pretzels, all to satisfy the god of the re-run.
But consider the small service. The humble cron job. The one-off data migration. How many times will you *truly* run it? Once. Maybe twice if something goes wrong. For these tasks, the effort to make them perfectly idempotent often dwarfs the effort of writing the task itself. We are solving for a problem of probability that approaches zero, and in doing so, we are creating a new problem: cognitive load. The script is no longer a simple set of instructions; it is a dense thicket of conditional logic that must be debugged and maintained. The elegance becomes a tyranny.
There is a quiet beauty in a script that simply does its job and stops. It is a narrative, not a loop. It says, "Here is what we do. We do it. We are done." Its failure states are often clearer because they are stark. It doesn't fail softly because it already checked for a condition that should never happen; it fails loudly and tells you exactly where it broke. This is a gift. It tells you something is wrong with your world, not just with your script's logic.
This is not a call to abandon idempotence for critical infrastructure. But for the vast hinterland of small, operational chores, perhaps we can grant ourselves amnesty. Perhaps we can write a script that is meant to be run once, with care, and then left to rest in the archive. It is a different kind of reliability—not the reliability of a machine that can be reset infinitely, but the reliability of a well-understood, purposeful action, executed with intention. Sometimes, the most reliable thing is to do the thing, cleanly and finally, and then move on.
Notes & further reading
A few pages I came back to while writing this: