The Rule of One

Automation is one of the most important tools in the software engineer arsenal. For many engineers, and particularly DevOps folks, automating manual tasks is their principal activity. Many software engineering challenges boil down to figuring out how to automate a task people previously thought had to be performed by humans, who usually charge more per hour than computers. The sociopolitical ramifications of this forward march of technology are an interesting topic, but outside the scope of this essay.


Somewhere in my education as a software engineer — I cannot recall where — I was introduced to a “Rule of Three” axiom for when to automate a process. The general idea is: when you have to perform the same task a third time, you should write a program to do it for you, automating it, instead. The logic behind this is not difficult to understand. At first you don’t know when or how often a task will need to be repeated. Automation is assumed to be significantly more expensive than manually performing a task, and you want to be efficient. When you’ve gotten to three repetitions it seems likely the task will be required several more times. Furthermore, you are now experienced at this task, having performed it at least twice before and should have all the required knowledge for automating it.


I’m not sure how, but the “Rule of Three” baked in pretty strongly to how I thought about problems for my first few years programming, until a later mentor suggested it was straight-up wrong. A more appropriate rule would be the “Rule of One”.

The thesis of the “Rule of One” is that truly non-repeated tasks in the software and IT world are relatively rare, and the cost-overhead for automation is typically not very high. You automate constantly as part of your job. Write a program to do it the first time. If it’s a task you don’t know how to automate, then it’s an engineering challenge and this rule may not apply.

I’ve found the Rule of One to be weirdly profound with a number of useful side effects when followed.


When you perform a task manually, finding a record of what you did later on can be challenging. You may also forget *why* you had to perform the task, particularly if it’s a few months between executions.

The Rule of One reduces deviations from expected state, because all changes are de facto documented (in code form) and easily packaged with notes on why the changes were necessary (in code comments). Changes to procedures can be easily tracked in version control systems.


A common ritual I’ve observed is the communication of a “required dev update”, typified by an email with instructions along the lines of “perform these steps after you next pull down code updates, or your dev environment may break”. Generally it comprises some set of tasks not captured by the existing build system. Now, I’ve already documented a procedure and sent it to my coworkers. This task is already repeated. It’s repeated by everyone I sent it to, presumably.

With the above example, sure I could write a migration script and send it out replacing a set of tasks with a single command, but I’m still requiring manual steps to be taken. Everyone still has to perform that “one time” task of running my script (and reading my email). The Rule of One asks: why aren’t these tasks captured by the existing build system. Are migrations of a similar nature not likely to be required in the future?

Every time you document a procedure, the Rule of One asks why it isn’t a script instead. Then it asks whether you could automate knowing that the script needed to be executed in the first place, removing the last two steps of

  1. Find the correct script to run
  2. Run the script

Every time you mass mark-read emails the Rule of One asks why you don’t have better filters, and then asks why you received the emails in the first place.

The Rule of One changes how you think about your job, by forcing you to recognize the manual tasks you do without even realizing you do them.


Ultimately, the Rule of One tells you to stop *doing* things. Your job is not to do things. Your job is to make computer do things. Computer remembers what you told it to do. Computer does not accidentally skip a step. Computer does not make typos. Computer does not get bored. Computer is your friend.