«Things are going to get difficult without automation.»

Andrew Clark is a Principal Engineer at Paranor and our resident expert for all things relating to automation. He helps external and internal customers to keep their build and deployment pipeline up to date with the state of the art. In our meeting, he told us what he finds particularly interesting about automation.

Andrew, how long have you been involved with automation at Paranor?
It seems I have been working on process automating in one form or another for most of my professional life. For Paranor it started in 2009 when I was involved in extending the existing compilation tool-chain to a general build and deploy tool-chain. We had to write most of the build/deploy framework ourselves as the language involved (Ada) did not have the support that other languages (e.g. Java) have in this area. The framework grew, and we ended up with a heterogeneous automatic build pipeline, that ended up including Java support. Writing the framework from scratch gave me a particular insight into the challenges involved in automating this process.


Where does your interest in this topic come from?
When I was introduced to continuous integration/deployment as part of the agile development process I started to realize just how much could be achieved with automation in this area. The tooling in build, deployment and orchestration, especially in a distributed/cloud environment, is being advanced at a remarkable rate. This makes it one of the most exciting areas in software development at the moment.


In your opinion, what are the most valuable advantages of automation in the IT sector?
The obvious advantage of automation – irrespective of what is being automated – is to free up time for other tasks. Specifically, with developer time at a premium, automating the development process allows the developers to concentrate on solving customers problems without getting bogged down in the details of how the solution is going to be produced. 

Another important aspect is error prevention. If a task is automated, it is always executed exactly the same way and the error rate is very low. Also, automation tends to lead to standardization. You can automate highly customized processes, however even then the configuration and communication is usually standardized. Standardization reduces the process's learning curve.

Finally, in order to drive automation you need to have machine understandable instructions - AI automation notwithstanding. With good tooling these instructions are – largely – human readable, this reduces the documentation burden for software projects. The documentation can concentrate on design and concepts with much of the detail being in the process configuration - many tools refer to this as "configuration as code".


What are the limits of automation?
While automation can be of huge value not everything can or should be automated. If you have a complicated manual process that is not understood, automation is not going to solve this, i.e. you cannot automate a process you do not understand. First you need to examine and understand the process. Automation is often the motivation for this exercise but not the solution in itself.

Do not automate a broken process. First fix the process and then automate it.

Processes with little repetitiveness are often not worth automating as configuring the automation is more work than doing the job. 

You cannot automate creative part of tasks.


What else would you like to automate?
At Paranor I would like to automate the testing and deployment of the development/deployment tool-chain itself. Automation has allowed us to speed up the pace of our product delivery, it should enable us to speed up the update cycle of our tooling.