Right Level of Automation

I believe in automation and CI/CD...it's what I do for a living. So I think about automation a lot. I also have lots of conversations about automation with peers. I also have some contrary opinions about automation.

Here's an opinion that seems to get me in hot water sometimes: "Not everything needs to be automated".

OH MY GOSH, CHRIS, WHY WOULD YOU SAY SOMETHING LIKE THAT?????

Look, automation takes time and skill. If you write code of any language, even "simple" shell scripts, what you have left is an artifact that has to be maintained...call it "tech debt" if you like. Let's examine some of these.

SKILL

I don't know about where you work, but I'm yet to see entry-level IT folks who can write automation scripts. This is okay and makes complete sense. If you take any Windows or Linux courses, you learn how the operating systems work, but you only have a small section on scripting (PowerShell or bash). You have to have several years of experience in the workplace, writing scripts, to be "good at it." Scripting, and therefore automation, is just another skill that takes a while to build. YOU, yes, YOU, have teammates who don't know how to write automation scripts. They, too, must get their jobs done. Don't hinder their work or their career development because of some automation requirement.

TIME

Automation takes time. It is NOT faster than doing things manually. When you do automation, you eliminate risk on the back end of your changes because you know the automation is repeatable and you (should have) tested everything out before running the script in production. That risk elimination means instead of putting time in after a change to check or fix things, you've put time in BEFORE the change.

A manual step that would take 10 seconds in a UI, might take you several hours to script, validate in lower environments, and publish to whatever CI/CD system you use to run the script. Understand this before you ever decide to automate stuff.

TECH DEBT

Especially on larger automation projects, when you automate, you are left with is a stack of code that must be maintained. Sure, you can believe "once my code works once it will work forever", but that is completely false. APIs change, business team names change, permissions change, you name it. You might write it once and have it work today, but there's no guarantee that your automation will work tomorrow.

You must maintain your code forever if you expect it to work forever. Things as simple as "naming standards" can screw you down the road if you don't keep your code up-to-date.

WHAT THIS MEANS

Automation is important, fun, and very useful, but you have to weigh the pros and cons before you declare that you "need" to automate a process. I have no exact formula to help you make your decision, but some of the points you should consider:

How often are you going to perform the task?

If you are automating a task that is never going to be run again, then just forget it and do it manually. Unless it's a very complex task, I don't think it's worth automating unless you are going to have to perform it once or more a month.

How complex is the task?

Don't spend your time automating something like "clicking a couple checkboxes in a UI". That's silliness. An entry-level support tech can do that with some basic guidance. However, if you have a largely complex task that you plan to do two times, it is worth putting in the time to get the first one right.

Do you have the required permissions to do the work manually?

It's fairly common to have fewer permissions on your personal user account than on a shared "service account". If this is the case, you may very well have to do some automation work to run your changes as that service account. If time is not an issue, this model works well. If there's a time crunch, it's reasonable to have an elevation method to let a person perform tasks manually. Never believe that such a method doesn't exist....there's ALWAYS someone who can make the change manually, even if you don't know who it is.

Do you have the time to wait for the automation to be figured out?

My goodness...This should go without saying, but I know it has to be said. If you are bleeding money or something is actually broken, fix the problem NOW. Forget about piddling away at testing some script to fix it. Fix it manually and then figure out how to automate the fix, but only if it is something that you feel may recur.

If your budget is running thin and your project success is on the ropes, GET YOUR WORK DONE. Don't let your own beliefs in automation hinder your project's success. Being productive is more important than following an "automate everything" mantra.

Conclusion

Just like everything else, there are pros and cons when you decide to automate processes. There is no one-size-fits-all rule. Think about them before deciding to do the automation.