I had a really interesting question on a powershell course I was running last week:
“How do I know what to automate?”
It’s a fair question. The glib answer is “anything that takes less time to automate than you will spend doing manually over the next three years” so… you have a task that takes you five minutes to complete, every morning. It will take four hours to automate.
5*5 = 25 minutes a week
Over three years, that’s 62 hours. Four hours spent up front to recover 62 hours is good work. Automate that. Stick 58 hours on the tracker.
Say you only do it once a month, though…
5*36 = 180.
That’s only three hours. It’ll take longer to automate than you will save. Frankly, don’t bother. Except…. Maybe you’ve got four hours free, and you will learn something by automating this particular task. This is still a useful exercise, even though it’s not going to save you any time. It should be an activity for the mythical “white space”.
There are more scientificish ways of determining what to automate, though. Before getting into them, we should perhaps consider *why* we automate.
From an organisational point of view, there are three reasons:
- more precision
- more stability
- more speed
Increased capacity and lower costs are desirable side effects from these three goals. From a human point of view, though, there is another one; less toil. Toil is the work we do that provides no other benefit than completing the task. We don’t learn anything from it. We get no pleasure from it. It’s like scrubbing the tiles in the bathroom with a toothbrush. Someone else’s bathroom. Our toothbrush.
When we automate toil, we get a double benefit; firstly, we can do something more interesting in that time, and secondly we learn something. Thirdly, we don’t get grout on our toothbrush.
Do I need a tool, or do I need automation?
I’m not going to get too bogged down in this, but it’s worth drawing the distinction. Tools make things possible, like a screwdriver, or very much easier, like a DeWalt 18v hammer drill. It’s still you putting up the shelves, though. Automation is when you come home to discover that the shelf elf has paid you a visit. Receiving a requirement for a new server, gathering the details and running a build script is using a tool. Automation is when the raising of the requirement, whether through a user request or through an alarm triggered by monitoring, results in the creation of a new server without you having to intervene in any way. Tools are good, automation is better. For the purposes of this article, though, let’s not quibble.
Here comes the science:
There are three commonly cited principles for planning automation; left-over, compensatory and complementarity.
This is poorly named, and comes from the over-simplification that “we automate everything we can, and people do what’s left over”. In fact, it’s somewhat more nuanced than that. It starts from the observation that any task can be viewed in terms of two dimensions – difficulty and frequency:
A task that is easy, and done rarely, will offer little return on the effort required to automate it, so just put up with doing it manually.
A task that is easy and frequent is ripe for automation. Whether it’s easy to do manually, or easy to automate, it doesn’t matter.
Tasks that are rare and difficult, such as troubleshooting and disaster recovery, should be improved through toolmaking, careful documentation and if, necessary, calling in outside help, like PTSG (cough).
Tasks that are difficult and frequent should be automated, but will require the acquisition of toolsets or products to help with that automation, such as Ansible, puppet, Jenkins, service now and so on.
This is based on Fitts List, published in 1951:
65 years on, and it’s still applicable, as argued by De Winter and Dodou in 2011. Automation based on this principle would consider which entity is better for the task, a computer or a human.
This views automation from a human perspective, and considers the effect of automation on the person performing the task, much as the fits report did; for instance, using automated landing routines consistently will reduce, over time, a pilot’s ability to land the plane, therefore using a complementarity approach the pilot and the automated system would share the task, allowing the pilot to remain sufficiently skilled that when situations arise that the automation cannot handle, the pilot is still able to take over. it produces systems that augment the human experience, rather than reducing or eliminating it. There is functional overlap, so that the amount of automation is flexible each time the task is performed.
Of these three, the “left-over” principle is the most commonly applied, but it’s worth considering any prospective automation from the other two viewpoints as well.
…there is the alternative to automation, which we should be familiar with from our constant application of lean principles; elimination. Is the task actually necessary? Is the output required? Is there an easier way to achieve the same endpoint? Is it Muda? if the answer is yes, then… stop doing it.
Limoncelli, T., Hogan, C. and Chalup, S. (2017). The practice of cloud system administration. Boston: Addison-Wesley, chapter 12.
Limoncelli, T. (2008). Time Management for System Administrators. Sebastopol: O’Reilly Media, Inc., chapter 13.
de Winter, J. C. F. and Dodou, D. (2014). Why the Fitts list has persisted throughout the history of function allocation Journal of Cognition, Technology & Work