Developing software can involve quite a few tedious or error-prone processes: Building or compiling code, deploying your software, installing/providing correct dependencies, running static analysis and code quality tools across many projects, running automated tests… the list goes on. All these processes carry the mental overhead of having to remember how to perform them, and require robust, up-to-date documentation to be written in order for everyone to be able to follow along consistently.
As an example, I have recently been focusing on providing team members both inside and outside of the UI team with several automated command-line tools that “just work” without having to remember every detail of several multi-step processes. Often it’s been possible for me to reduce those processes to a single command. As for documentation, it’s provided by simply typing the command name without any parameters, which means it’s always available exactly where and when you need it. This way the team can free their mental energy to focus on coming up with solutions to new and exciting problems rather than continually butting up against the same issues.
If a complicated process can be abstracted away into a simpler process, it lessens the need for complex, detailed documentation, which can be difficult to repeat exactly and is subject to human errors. On the other hand, if I have a script, or automated workflow defined, it lessens the need for me to write lengthy documentation about the process, since it becomes unnecessary to think deeply about the underlying details. The process is abstracted away into a single step! In cases where we do need to see the details about how things are happening it’s still all right there to find in the form of code, logs, or workflow definitions.
Pitfalls of Automation
Even considering all the benefits of automation, it’s important to note that it doesn’t always come for free. Many automated tasks have their roots in the labor of someone poring over a computer or machine manually punching keys, clicking buttons, or pulling (virtual or literal) levers, and making decisions to get the job done. This labor represents the knowledge required in order to perform the process, and this knowledge must be taken into account and understood very well before attempting to automate. To put it more simply: you can’t automate something if you don’t have an extremely strong grasp of the processes involved, as well as their edge cases.