Learning at Work Week: What is Automation?
17 May 2018 |
Mike Steel | About a 4 minute read
Automation is nothing new; if anything it is one of the most ancient differentiators of modern humans from our prehistoric counterparts. What is a simple windmill if not the automation of hand-grinding corn?
The reason the industrial revolution, let alone the computing revolution, came about was because of the power of automation. Two hundred years ago we saw manual tasks being replaced by machines. Steam and iron replacing people-power and muscle.
We are so familiar with automated processes now that we barely notice them – from traffic lights to Alexa. In short – anything that a machine can do instead of a human is automation.
So what if those machines were faster, cleverer, and able to make decisions for themselves? How can we use it to power our development lifecycle and the projects we work on?
Programmers are automators.
We may not always be aware of it, but programmers and engineers are the people who automate. It’s what we’re hired to do.
Build a price converter so a user can swap to their currency on the website rather than them having to calculate it manually.
Write a query to aggregate our analytics from our different websites and report on which pages have the highest bounce rate.
These are mundane tasks that many developers are building their own versions of today across hundreds of different companies.
Automation as a developer mindset.
While we may build processes to make other people’s lives easier, we don’t always have it as a mindset for ourselves. The more tasks we can leave to a computer to handle, the more time we can focus on the things that require a real live human (…for now).
Most development teams will already automate at some stage of a project. Continuous integration pipelines is one example of this long standing trend.
This approach can be taken towards any task, but is most effective at targeting repetitive, simple processes. Tasks that have little variance in the input can be the easiest tasks to automate.
It’s not just about saving time; if you have a computer do something for you it will always be more accurate and (normally) more reliable than its human alternative. Human error has led to plenty of anecdotes about accidentally deleted databases, a computer will never make a tired mistake.
Automation, of course, saves time. This doesn’t just benefit the task itself. An automated process is one you don’t have to spend time teaching new team members to perform.
For example, new team members don’t need to be talked through how to format their code if there is a linting file to integrate with their editor and format checking on any code that they try and add to the project repository.
Team members should still know how to perform these tasks manually if necessary, since automation should be seen as a tool to help rather than something to rely on.
Automation is no silver bullet.
Firstly, just because you have the right skillset in the team to perform the task, doesn’t mean you have the right skillset to automate it.
Then there’s the time it takes to automate the task. If you spend a minute a day on a task, is it really acceptable to spend a week automating it so you never have to do it again?
As an example, if you do a task daily and you can save 30 seconds of time then you should spend up to 12 hours trying to automate it.
This needs to be taken with a grain of salt – in brackets under the heading of the xkcd comic you’ll see that it is based on whether you will have saved time after five years. I have only ever seen a few examples of the same process being used in software for five years.
The best insight I had when I was introduced to developer automation was to stop relying on GUIs – learn terminal and bash scripting alternatives. With the right trigger, these can then automate processes that were previously manual tasks.
And don’t be afraid to play around with different tools. One of my most successful tools was a simple Chrome extension to validate a few window variables and immediately report on a website’s technical set up!Read More From This Author
Programme Director (Edinburgh)
Bring your expert project knowledge to the table to own delivery of all our initiatives being delivered out of our Delivery EngineI'm Interested
Engineering Director (Edinburgh)
Bring your expert tech knowledge to the table to own key technological and architectural decisions for our Delivery Engine.I'm Interested
Onboarding Co-ordinator (London)
Play a key role in inducting all our new starters through AND’s award winning onboarding experience!I'm Interested