One of our star developers publically pondered whether to automate his latest problem: the diagnosis of an elasticsearch cluster.
The hesitancy in our discussion took this tone:
Automation costs time, and you may not recoup that time.
To back up the thought, a well circulated xkcd comic was dropped in our #development channel:
This line of thinking never sat well with me.
Could it be that simple? I tell this equation how often I perform a task and how much time it takes. In return, it tells me the maximum amount of time I can spend automating it?
The one minute spent rebooting the elasticsearch cluster once a month weighs in at a single hour of script-writing?
No way! Don’t you dare submit to this defeatist attitude. There’s so much more at stake here…
Knowledge Acquisition
Suppose your first automation takes you six hours.
Perhaps you’re not used to writing scripts? Maybe your node is rusty, or you’re unsure how to connect directly to your elasticsearch cluster?
Surely your second script won’t take nearly as long. You’ll likely re-use parts of the script, and you’ll be better versed in the language. The connection details become familiar boilerplate or a shared module. Each subsequent script takes you less and less time..
Without biting the first few proverbial bullets, you’ll never hit the escape velocity needed to automate with ease.
In the software industry, perpetual knowledge acquisition is the norm; this is but another opportunity to show your mettle. Not only will your future self thank you, but your present day colleagues will thank you as well.
Automation is Caring
The time sunk vs time saved matrix is self-centered; it’s not a team player.
Suppose your organization has five teams, each with five clusters. Even at these modest numbers, it’s clear that you don’t want to manage these resources manually. Your teammates, present and future, want to manage them even less than you do.
The responsible thing to do is to write and distribute scripts to manage these clusters automatically.
Remember how our chart granted us one hour to write a script for a single minute task, carried out monthly? Multiply this time by the number of teams that could also use the script.
You now have five hours to write the script. That’s better, isn’t it?
The Mental Tax
Employees of all persuasions can feel when their time is being wasted. From the secretary manually penning cheques to the dev-op manually deploying across several servers.
The periods spent in tedium are likely to feel increasingly burdensome as time goes on, and lapses in focus will eventually lead to accidents.
Use your working hours to focus on valuable, creative tasks, not busy work.
Employees will be happier if they’re producing or enhancing. I certainly am.
Accumulating Debt
Alan Turing rolls in his grave every time a developer carries out a manual procedure.
How many thorns should one tolerate? A single manual task per day? Two? A combined ten minutes of manual procedures? Surely not more than 20 minutes per day?
Zero is the ideal, of course.
Be leery of accumulating debt in the form of procedures, as this debt comes in many forms. Be vigilant in identifying it, and fight your battles early.
Making Your Decision
The “should I automate?” equation is clearly not as simple as some purport.
In terms of sunk costs, we have…
- The time you spend writing the automation.
On the other side of the equation, meanwhile, we find these benefits:
- The time you save with the automation.
- The time your team-mates (and others) save with the automation.
- The knowledge you gain during automation.
- The empowerment gained by creating a useful tool.
- The mental anguish you save in not carrying out repetitive tasks.
The value I place on knowledge and creativity leaves me with a wonderfully lopsided balance.
I say automate.
Comments