The Humble Doorstop: A Lesson in Idempotent Operations

On the floor, tucked against the baseboard, is a simple wedge of rubber. It’s a doorstop. Its entire purpose is to be placed, to hold a door open, and to be removed. It asks for no power, no configuration, and no monitoring. It just is. In our world of complex systems, we could learn a thing or two from this unassuming object, particularly about the elegance of idempotent operations.

An idempotent operation is one that can be applied multiple times without changing the result beyond the initial application. Kicking the doorstop into place is idempotent. The first kick secures the door. The second, third, or tenth kick does precisely nothing to change the state of the system. The door remains open. The operation is safe to repeat, even unnecessarily. It doesn’t error out because the door is ‘already open.’ It doesn’t try to open the door ‘more.’ It just ensures the desired state is achieved.

Contrast this with so many of our automated scripts. We write a task to ‘start’ a service. Run it once, it works. Run it again by accident, and it might throw a fatal error because the service is ‘already running.’ This is not idempotent. It’s brittle. It creates noise in logs and anxiety in our hearts. The doorstop doesn’t care how many times you nudge it; its outcome is consistent and predictable.

The Wisdom of the Wedge

The doorstop teaches us to design for this state of being. Our scripts should be wedges, not levers. A script that checks if a backup has already run today before initiating a new one is idempotent. A configuration management tool that ensures a line exists in a file, regardless of how many times you tell it to, is idempotent. These are reliable, boring, and profoundly effective.

This principle extends beyond code to habit. The daily ritual of checking a particular log file or verifying a key metric is our way of gently kicking the doorstop. We are ensuring the state of the world is as we expect it to be. Doing it once is diligence. Doing it twice changes nothing about the system’s reality, but it might change ours, reinforcing the pathways of vigilance. The action itself is idempotent, but its repetition builds a reliable practice.

In a field obsessed with automation and complexity, the doorstop is a monument to simple, state-based assurance. It doesn’t need to be smart; it just needs to be effective. It is a single-purpose tool that excels at its one job through a fundamental, mathematical property of operations. The next time you write a script or craft a cron job, ask yourself: is this a doorstop? Can I run it a thousand times with the same, calm result? If the answer is yes, you’ve built something truly trustworthy.

Notes & further reading

A few pages I came back to while writing this: