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.

As anyone who has spent a long time writing automation tools can attest, it doesn’t always make sense to automate every task yourself. Sometimes it takes a while to realize that something can or should be automated. If you don’t fully understand the pitfalls and edge cases involved, the work of automating it can actually be more time-consuming, tedious, and error prone than just manually performing the task.

Of course, the best kind of automation is the kind where someone else has already done the legwork of finding edge cases, learning from failure, and finally implementing a robust automation solution. As developers, we have our fair share of solutions like this: Continuous integration servers, package managers, and IDEs, are just a few examples of out-of-the-box automation our developers use every day to help automate the more tedious processes of building, deploying, and managing code. The draw of these tools is simple: the automation already exists, just plug in your parameters and let the software do the work!

The Future

What’s next in the realm of automation? Allowing partners to become more effective through the power of consistent workflows, actionable reporting, proactive insights via machine learning, and more. I’m excited to continue working toward the future of automation at BitTitan and to see where it takes us and our partners!