Devops: why it pays to automate

Quite a few people in the software development and system administration industries have seen the now-classic XKCD vignette about automation.

The central point of the comic is that effort invested in automation of a task — especially one rarely done — often wastes more time than it saves.

As the guy who inquired to a factory why cans aren't made in optimal proportions to save material, Randall also focuses on a single benefit to the exclusion of all the other reasons why automating a task is a great idea.

We don't primarily automate to save time.  Saving time is great, and it is necessary to achieve things at scale.  But time is not the central reason why we automate.  There are other motives.

Consistency and repeatability.  Doing things manually, especially if multiple people are doing it, always leads to inconsistent approaches, even if the process is well-documented - humans being humans.

Improvability and evolvability.  It is easy to keep adding features, exceptions, etc. to a script but way harder to add that to a manual process.

Knowledge management.  When "how this was done" is written in descriptive or executable form, future-you-in-six-months stand a chance of figuring out what was done, and possibly why it was done the way it was done.  Especially when the automation involves declarative code, it beats written documentation in specificity and practicality.

Transferability.  Automated processes make it possible for others to carry out your work as if you were doing it.  It’s like there’s a duplicate / ghost of you sitting beside them, guiding them along.

The value of this proposition grows with the size of your team too — do you want to be caught in the position where you are the "only guy who knows thing", and others need "thing" fixed right this instant?

Certainty and reliability.  Once a task has been sufficiently automated, you can often augment it with e.g. telemetry and logging, to give you advance or rapid notice when something goes wrong, and to debug the problem with less effort.

Leverage.   A sufficiently-automated task can be set to run on its own and inserted into a larger pipeline — in short, it can become part of a much bigger whole — a real lever to help you move larger things with less effort.  Think of the enormous difference in results and development pace between manual acceptance testing and continuous integration.

Learning.  Automating a task often leads you to learn about the thing you're working with, way more than just simply performing steps manually.  You usually learn not just the what or the how, but also the why.

Fun!  It is more fun, and certainly less tedious, to write a script or a declarative manifest, than to do something manually.

That said — if the manual process was going to only take a few minutes, it is unimportant to remember the steps, and won't ever need to be repeated — an awfully infrequent exception, especially when working at scale — I might skip the automation if there was something more interesting to automate.  More often than not, however, when I skip automating it, future me regrets it.

This post was inspired by a clever redditor.