I’m one-and-a-half courses deep into my Automation for IT Google Certification program on Coursera, and was just reminded of some of my own personal experiences with working in the Tech field over the years. At this stage, the topic of deciding when to automate versus when to leave something unchanged has come up. I’ve actually encountered this dilemma twice already, despite never doing any professional automation in any of my previous job roles. These two instances resulted in both a triumph and a failure each.
The Value of Automation
At this point in the course, the instructor aims to hammer in the importance of task automation as an IT Administrator. To do this, he opened up with the Pareto Principle, also known as the 80/20 rule. It suggests that roughly 80% of effects come from 20% of causes. In the case of IT Administration and Automation, it means that 80% of your time savings or efficiency gains can be achieved by automating just 20% of your regular tasks.
Have you ever wondered how your company’s IT Admin can seemingly slack off most of the week, yet still keep up with his regular workload? The answer is probably that he automated that 20% of his work already.
The “Is Automating This Worth It?” Formula
Next, the instructor dove into the details of how one could determine whether or not automating a task is worth the effort to do so. The approach is seemingly basic, but comes with a lot of abstract problems that we’ll get into later.
- Estimate the time required to automate the task. This task shouldn’t only include your time estimation of simply opening Notepad++ and banging out a script. You will likely need to conduct research, perform testing, and handle deployment in addition to development.
- Account for the time it takes to do the task manually once. Hopefully you’re good at time-tracking your tasks. I always end up with a stop watch that I forget to stop, and leave open in the background for hours.
- Multiply that time by the frequency of the task over a suitable time period. This could be months or years, depending on the nature of the task and the expected lifespan of the automated solution.
- Compare. If the time spent doing the task manually significantly exceeds the time it would take automate the task, then it’s a good candidate for automation.
Simplified:
If (Time taken per manual task * Frequency of task * Time period) > Time taken to automate, then consider automation.
Successful Calculation
My first experience automating came not from a job requirement, but out of my own desire for sanity in the midst of a work-related crisis. My company was chasing down an elusive, highly intermittent, yet critical bug.
My job seemed simple at first, update our servers with a test BIOS, configure the BIOS settings to a specific formula provided, then launch an automated test that would run for days. Unfortunately that was not what actually happened.
Instead of getting a test BIOS, completing a round of testing, then getting a new test BIOS days later, I was getting a several new test BIOSes per day, sometimes with a new BIOS setting formula to apply. My life was suddenly consumed by the tedious process of halting all tests, applying the new BIOS, configuring the settings, and relaunching the test for dozens of test servers. By the time I finished, I would check my email and see that I had gotten a new BIOS to test 30 minutes ago.
When I finally caught a break from the madness, and my tests were allowed to run uninterrupted for longer than a few hours, I opted to work until midnight, configuring my own automated process to achieve the rapid turnaround I was expected of me. I did this knowing that this brief respite was merely a pause, as project managers and developers alike would soon return to their bug-hunting frenzy.
Fortunately for me, our automated framework required minimal coding knowledge. Instead, it involved digging into some obscure settings files of an in-house automation software that I was already familiar with. configured the system to automatically target a new BIOS file in our shared network folder, update the BIOS, adjust a simple text file to match the settings required for the test, and launch the test upon completion. Although it took hours of overtime, this script saved me from working over the Thanksgiving holiday, which would suddenly overlap with this ever-expanding emergency.
Calculation Failed. Reason: Hubris
Shortly after savoring the sweet victory over the melodramatic panic of project managers, I was faced with a new crisis in my coveted personal realm.
I moderate a sizable Discord chat server associated with the /r/WarcraftLore subreddit, and the unthinkable happened when one of my fellow moderators fell victim to a group of hackers. I was the only moderator active when one of our own suddenly started spamming the server with nonsense, and systematically banning all non-moderators from the server.
In the aftermath, our modest team of three volunteers faced the task of manually unbanning over a thousand users without readmitting the trolls, all in an effort to save our server. At this point, I, a guy with no experience programming Discord moderation bots, believed I could create an automated solution more quickly than it would take to manually click through the extensive list of banned users for several hours.
Several days, and late nights, later I came up with a solution that only worked for maybe 90% of the affected users.
What happened? Well, even though I was capable of automating this task and could have executed it more effectively given time, I underestimated the prerequisite knowledge needed for its completion. As it turned out, acquiring a basic understanding of Python and a significant portion of Discord’s API was not doable for me in only a matter of hours.
When Time and Effort Estimations Fail
Though automation effort calculation is valuable, I believe that new programmers and IT professionals will always have to acquire this complex and nuanced decision-making skill the hard way. The reason is that beginners often struggle to estimate the time and effort required for a project. Or at least that’s what I assume, since every experienced developer I’ve spoken to has been unable to adequately explain their approach.
Additionally, it is unlikely that any mentor you consult can fully grasp your level of knowledge, understanding, and skills, all of which are necessary to determine the time it would take you to complete a task compared to themselves. Conversely, you will not be entirely aware of your own professional requirements for this task either. You may not even know which questions to ask your mentor or trainer.
Much of what developers discuss comes with an implied piece of knowledge, something they assume anyone at their level already comprehends. I witnessed this daily at work, particularly as a QA professional, furthest down on the totem-pole yet expected to keep up with the jargon and advanced technical concepts hurled at my incessantly during stand-up meetings.
All that to say, don’t be disheartened if you make mistakes in this calculation once, twice, or even numerous times before mastering it. From my experience, overcoming this early hurdle seems to require a considerable amount of trial-and-error. This means a whole lot failure, and persevering. Stick with it!
