Automation - The "Script it" versus "Do it" continuum
The "Script it" versus "Do it" continuum
A recent tweet from @nickrusso4258 got me thinking about something I've been trying to express in my professional (don't laugh, people sometimes say I am) life for a while now, that can strike a nerve with the "Automate ALL THE THINGS!" crowd; scripting something (and by extension automating something), isn't always the right answer for an Organisation's use of Time (read: your 9-5 they pay for).
As I appreciate that not everyone is a Coder, DevOps or new-kid (some of us still get paid to be Cisco Mario; not everything is up in Toad Cloud yet...), this concept can apply a little wider than just to Developers, and even probably to the Business-y people all us IT Folk interact with on the daily. Using my finely-honed MS Paint skills (side-note: you've not lived until you've done a Network Diagram in MS Paint), here's a sexy graphical approximation of the theory:
Making stuff up #1 - Payback sweet spot
What the graph is trying to demonstrate is that the world of repetitive tasks can loosely be split into two partisan camps:
- "Script it"
- i.e. Put the additional effort (more than to just "bang another <repetitive task> out") in, and automate it/script it/somehow make it easier to perform than just doing the do over-and-over, with two tangible outputs:
- Completion of <the task>
- Automation of <the task>
- i.e. Put the additional effort (more than to just "bang another <repetitive task> out") in, and automate it/script it/somehow make it easier to perform than just doing the do over-and-over, with two tangible outputs:
- "Do it"
- i.e. Don't worry about the why, just repeat the manual steps you'd normally do and "bang another <repetitive task> out", with one tangible output:
- Completion of <the task>
- i.e. Don't worry about the why, just repeat the manual steps you'd normally do and "bang another <repetitive task> out", with one tangible output:
The obvious sweet spot here is that, for a given number of repetitions of <the task> over time, eventually the additional effort of "scripting it" (the time taken to do the automation, on top of that of just <doing the task>) will eventually pay itself back, as after a given "Payback sweet spot", you've now got time back to do other stuff, which you'd otherwise have spent just doing <the task> again and again.
Alright, I'm buying it #2 - Positive opportunity cost
Or in other words, you're now in "Positive opportunity cost" - that is, <the task> is in someway automated, and you can dedicate your time to the other fifteen-million items on your "To Do" list, instead of this <task>. All is well in the world, you've automated all the things - and bar a little troubleshooting and debugging you unexpectedly have to do (i.e. when you discover your vGhetto VCB Cron Job uses a file that gets overwritten at ESXi System Reboot...), you're actually "earning time" saved through the script parallel-working the task for you.
Bully for you; your life is complete, you've moved all the things to teh Cloudz, and you're about to marry Princess Toadstool, and live in the Kingdom of the Mushroom Cloud forever mor...
Wait a minute, what's this #3 - Negative opportunity cost
But look over there on the left-hand side of this conceptual model; what's that pesky "Negative opportunity cost" all about then? I'm just about to pop the ring on Princess Toadstool, you saying I've got a problem here?
What I'm referring to here is the cold reality of Work; you're ultimately paid to produce output that a Customer wants - whether that's direct tangible stuff ("Hi, make this Network Switch go now please") or otherwise intangible stuff ("Hi, move these Apps to the Cloud? Mkay, you'll need to make a Project Plan for that, I get it...") - it's all output that's working towards a tangible goal.
You know what isn't output working towards a tangible goal? Scripting.
You know what you can't accurately do? Predict the future.
You know what the problem is here? Scripting a <task> that actually needs to be run, in future, with less individual repetitions of duration than just manually repeating the <task> would have taken you (and you get multiple lots of tangible output for that).
Let's give you a worked example; suppose you need to write a script to output all the IP Helper Addresses of a Cisco IOS Script, and (you don't know it yet), but you're not great with Bash Shell script (well, you do know that...), and it'll take end up taking you 16 hours. Sounds great; much easier than ripping through 500 devices and doing that manually, right - that'd take you maybe, I dunno, 5 hours and a bit of hand-cramp?
But what if I said to you that, unbeknown to you, we're about to swap out all that Cisco IOS kit for <SD-WAN Vendor XYZ> kit; where stuff like this (IP DHCP Relay Address) is pushed out in a programmatic, templated fashion anyway. What's happened now? Well, in Business Output terms, you've just wasted the time it would have taken to do it manually (5 hours) subtracted from the time it took you to script it and get the tangible output (16 hours), so you've cost the Business 11 hours of time you could have been doing something else productive.
Which would be 11 hours' worth of "Negative opportunity cost", and seems to be something the Automation Crowd rarely focus on; none of you are Mystic Meg; none of you have Crystal Balls; none of you can predict the future.
Something to dwell on. Meanwhile, I hope Princess Toadstool likes Hula Hoop crisps as engagement rings...