Automation Is a Panacea

Panacea  
noun  
a solution or remedy for all difficulties or diseases.

Obviously there are no panaceas, let’s downgrade it to “something that is good to do in almost all circumstances”.

According to the first citation in Wikipedia: “Automation is the technology by which a process or procedure is performed with minimal human assistance”. For our sofware engineering purposes, we’d think of automation as a “script” or program that runs a series of steps that were performed manually before — see “infrastructure as code” for example.

I’m going to cheat a bit and move the goalposts in my favor: since we have some script or code, it’s only a few ‘git’ or similar commands away to have that code in a version control system.

It’s all about performance, right?

Most people when they think about automation they think about performance; how something that took that much time to be done manually now it takes less time. See compulsory xkcd comic:

But automation is so much more than speed of execution for a task; I’d argue that’s often the least of its advantages.

Automation is Code

The key idea is that since automation is code, we get all the possible derived goodies from working with code. Granted, with the small extra effort of using a code repository.

• A whole category of errors (manual mistakes, arguably the most common source of errors) go away.

• Code reviews and regular developer workflow are possible, adding an extra layer of safety.

• Audit. We have the ‘what’ code was run. If this code is triggered by a system instead of manually (a CI/CD platform for example for tests or infrastructure) then we also get the “who” and “when”.

• Reduces toil work in teams. Favours project work vs reactive work.

• An operator – somebody without deep knowledge of the systems related to the action to perform – can run as well. Multiple people can use and benefit from this code.

• Code serves as a form of documentation, helping the dissemination of knowledge.

• Consistency. When something goes wrong, is because of a change. If different people may perform operations differently, this is a source of uncertainty and possible hard-to-find bugs.

Possible Downsides

As possible downsides we can cite:

• It’s more work (duh!). It’s more work at the beginning, yes. Like many good practices (having code repository, having tests etc) that need some initial investment before paying off.
• Amplifying a mistake. (Affecting many servers for ex), this is the “machine gun instead of knife” argument in terms of killing power. And yes, you can temporarily do more damage with a script that for some reason say affects way more servers than manual steps but still this mistake would be more advantageous than its manual counterpart; we could look at the code and find and fix the problem from that point on. A manual mistake may not even leave a good trace of what really happened.
• Maintenance. As any other code, things change and code needs to be updated.
• Rigidness. The code may be hard to change or adapt to new situations.
• Lack of fine-grain control. If the script is a simple list of commands that doesn’t check for results of previous commands or lacks other checks then a savvy administrator that can interpret a checklist and perform ad-hoc checks may be preferable for some tasks, but in principle there’s no reason why checks and logic can be added to the automation scripts.

It Doesn’t Have To Be All-Or-Nothing

Anything helps; there are options between having nothing to having “one-click” automation of a task:

1. Writing down instructions. For example, regarding a task to be done in a web interface. This can go from simple text instructions to documents with screenshots or small videos. Checklists are a great way to get started with documentation and automation.
2. Combining instructions and commands. Complex or lengthy tasks can often be broken down in shell/CLI commands and UI or other manual work.
3. Automating a task in a script with some instructions. User will probably have to change some parameters at the beginning of the script and the code may not be idempotent but this is already a great automation and automation-as-code step.
4. Finally, code (script, binary or declarative code in a tool) that automates completely a task. There are still several degrees of robustness within this category, for example:
   1. It can be run from servers.
   2. It can be called from other programs that can pass inputs to it.
   3. it’s solid enough to recover gracefully (for example, retrying a 3rd party service connection or restarting the task after a server crash).