To Script or Not To Script? That is the Question We Need to Answer
When to script and when not to script is our topic for today. I know myself and my audience; we’re all about scripting. We want to write PowerShell scripts for everything, but, unfortunately, it’s not always the best decision to do so. I know it sucks, but I’m here to hold your hand and tell you, “It’s okay! We’ll get past it.”
For example, you’re the PowerShell scripter guru extraordinaire at your small organization. You work with a handful of people that are in the same realm — helpdesk guys, other sysadmins, and network engineers.
Say you build a script that is keeping some service alive on a server, e.g., some critical business service that kicks off a scheduled task, then, you go on vacation, and that service faces a problem and something with your script goes wrong.
Because you’re on vacation, your company doesn’t want to bother you. Thus, your co-workers go in and look at your script and think to themselves, “What is that? I have no idea what’s this for! Where’s the button that I can click on?” They just have no idea what to do. As a result, they go through your script and try to decipher it — either they take longer to fix the issue or make the problem worse than it was in attempting to run it.
The first thing to do is remember the people that you work with when you wrote a script. When you write a script for your personal use and has nothing to do with business or any other team, that’s alright. However, once you start writing scripts that touch production, some critical server, and some crucial process in the business, that’s when things change.
You have to realize, “Okay! If I get hit by a bus, who’s going to maintain this? Who’s going to understand this?” They don’t have to know PowerShell or any scripting language as much as you do, but they do need to know how to understand it. You have to have a backup.
This is where a cross-training comes in handy. If you’re good at something, you always want to, at least, have another person to understand what you’re doing. This is the same thing with PowerShell scripting in general. Otherwise, nobody can understand your script.
I would argue that they need to be trained but if that’s not possible, it’s best to use an existing tool off-the-shelf, or they can go into a web interface, go to what they want to do, and manage it that way. That’s one reason that you may not want to use a script to solve a problem.
Time is another reason that may come into play. There’s a lot of vendors out there who have products that do something but PowerShell and other scripting languages, in general, can do everything every product does. But you just don’t have time to write them. You would prefer to write PowerShell scripts all day to automate everything possible, but that can’t happen. You’ve got other responsibilities.
Time management is important. If you can buy a tool off-the-shelf, that does what something that you want to write a PowerShell script to do, you should just get the tool and solve the problem, because you’re always going to have other areas of your job or career to automate script for.
I still struggle with time management even though I’m now a PowerShell developer. In my previous position, I would try to write PowerShell scripts and automate everything. It was a good idea because I had the time upfront and it saved time in the long run like any pieces of automation do, but there were times I would miss deadlines because I was busy writing a script when there was another tool available to you that saves time.
I didn’t get into major trouble, but I know that there are times when somebody says to me “Why is this task taking you so long when we just need to do this thing this one time?” And I’d respond with “Well, I’m writing this PowerShell script that will handle this situation, and all the ten iterations and ten years down the road sort of situation.”
I would get in trouble for that because I didn’t need to future-proof the script. It would have been much easier to just buy a cheap tool and use that instead.
It’s an excellent skill to be pragmatic about your other tasks. Even though you love writing scripts, you can’t script everything because there’s always that fine balance between the two.
This blog post was created from the transcript of my YouTube #CarTalks video called To Script or Not To Script? That is the Question. Be check out the YouTube channel and subscribe!
