The Fall of the Old Mill Wheel: On the Persistence of Idempotence

There is a mill, long fallen into disuse, not far from here. The stream still runs, but the great wooden wheel is frozen fast, its slats thick with moss. I sometimes walk there to think. The lock gate, a simple timber sluice, has long since rotted away, but you can see the groove it sat in, a scar worn deep into the stone by centuries of lifting and lowering. The miller would have dropped that gate a thousand times, perhaps ten thousand, to start the wheel turning. Each time, the action was the same: the clunk of wood into the notch, the redirection of the current, the slow, inevitable groan as the wheel began its work. The result was always the same, too, provided the stream held water. It didn't matter if he had done it an hour before or a year. The gate was dropped, and the mill turned. An operation, repeated, giving the same outcome.

We have a word for this in our world of circuits and scripts: idempotence. It sounds clinical, a piece of jargon from a textbook. But it describes the ghost of that miller’s action. It is the property that allows us to push a button, run a script, or send a command, confident that the tenth attempt will not wreak havoc where the first succeeded. It is the assurance that a service restart won’t create duplicate invoices, that a retried network call won’t charge a customer twice, that a configuration management tool can apply the same rules endlessly, only changing what is out of alignment.

We build idempotence into our systems like a craftsman builds a reliable joint. It is not the flashy feature; it is the hidden dovetail that holds the drawer together. Without it, our operations become a delicate dance, a series of one-time rituals that must be performed perfectly on the first try. A backup script that creates a new, uniquely named folder each time it runs is not idempotent; it simply litters the landscape with archives. An idempotent script, by contrast, checks for the existence of its target, verifies its state, and ensures that by the end of its run, the world looks exactly as it should, whether it had to build it from scratch or merely dust off a corner.

There is a profound quietude in an idempotent system. It absorbs the frantic energy of human worry and mechanical retry, turning it into steady, reliable state. The anxiety of ‘did it work?’ is replaced by the calm of ‘if it didn’t, we can simply try again.’ It is the difference between a Rube Goldberg machine, where one misplaced cog halts the entire fantastical process, and the old mill wheel, which only ever needed the water to flow and the gate to be dropped. The former is clever; the latter is dependable.

Standing by the silent mill, I think about the systems I tend. I wonder which of their operations are like the brittle, rotten sluice gate, demanding a single, perfect execution, and which are like the worn stone groove, shaped by repetition into a channel of certainty. Are my scripts millers, capable of reliable, repeated work, or are they acrobats, performing a trick that cannot be repeated without risk? The goal, I suppose, is to build things that are less like performance art and more like geology—processes that wear a reliable path through stone, so that the outcome is guaranteed, no matter how many times the water is let through.

Notes & further reading

A few pages I came back to while writing this: