Weekend Scripter: The Big Decision about Scripts

Summary: Ed Wilson, Microsoft Scripting Guy, talks about if you should write Windows PowerShell scripts or do something else.

Microsoft Scripting Guy, Ed Wilson, is here. It is the weekend, and once again, it is a beautiful sunny morning in central Florida. I am sitting outside with my Windows Surface Pro 3, and taking the time to do a little writing. I picked up some fresh bagels, and I am sipping a nice cup of English Breakfast tea with a bit of lemon in it.

As I reflect back over this week’s blog posts, I think I need to clarify one thing: the whole point of scripting is to make things easier. If it is easier to not write a script, then don’t. If it is easier to use the GUI to accomplish a task, then do it. Hey, with Nano-Server, we have a greatly enhanced server manager tool that is web based, and it is a graphical tool that can accomplish some powerful tasks in a simple and low impact manner. So writing a script, or even firing up the Windows PowerShell console, is not always the easiest thing to do.

However, I think that often Windows PowerShell is the solution. In addition, I also predict that for every minute you spend learning Windows PowerShell, you will gain 10 hours of additional productivity over your career as an IT pro. No, I don’t have any hard statistics to back that up, but here are the assumptions that I base this on…

Back in the old-fashioned VBScript days, I was a consultant for a boutique consulting firm. Before I learned VBScript, when I faced a task on a server, I would think:

“This task will take me four hours to accomplish. If I knew VBScript, I could write a script and it would accomplish the task in about 10 seconds. But because I do not know VBScript, it would take me at least 8 hours to find a sample script, modify the sample script, test the new script, and then run it. So in the long run, it is cheaper for the customer if I do this task manually.”

If I knew VBScript, I could have written the script in about an hour and saved the customer three hours of labor on the task. So one day, I decided to learn VBScript—and as they say, the rest is history.

If one does not know scripting, Windows PowerShell or anything else, there is always a huge amount of entropy to overcome. For most common, daily tasks, it will always be quicker to use some sort of GUI tool, or to cobble together a batch file by using various Sysinternals utilities and other tools downloaded from TechNet to accomplish the task.

But eventually, you will become confronted with a task that simply cannot be solved in the old manner, using the old tools and techniques, and then you will be forced to learn Windows PowerShell. And, if following Murphy ’s Law, it will always happen at the most inconvenient time, at the time when the staff is stretched thin, and you will have no other choice. That is why one of my video series was titled PowerShell: Learn it now before it is an emergency.

The key thing is to focus on the task. Don’t let the discussions of console, ISE, inline script, saved Windows PowerShell commands, functions, advanced functions, or modules side track you into a state of inertia. Windows PowerShell is a tool. Sure, for some, it is also a hobby. For others, it nearly borders on an obsession. But to the majority of Windows PowerShell users, it is a tool—a powerful tool, but a tool nonetheless. In fact, it is one tool among many potential tools.

I need to look at the task to determine if Windows PowerShell is the best potential tool. For example, I am sitting here this morning, sipping tea, and writing today’s post. I am using the GUI tool, Word, to do this. Sure, I could write today’s post “in PowerShell” by using the powerful automation API in Word, but it is not the best tool for the job of writing a single article.

However, when it comes time to create template documents for six months of Hey, Scripting Guy! Blog posts, you better believe that I am using Windows PowerShell to do that. I saw a script awhile back that uses Windows PowerShell to create blog posts. The text content was added in as Here-Strings.

Dude! To me, that was cool. But at the same time, it was rather silly. I prefer to use Live Writer when I am doing ad-hoc blogging. Could I use the Windows PowerShell script my friend wrote? Sure, but to me, it is easier to use the best tool for the job, which happens to be Live Writer at this stage of the game.

I have seen Windows PowerShell scripts that replicate the old Asteroids game, and the old Space Invaders game, but if I want to write a game, I will use Visual Studio and some of the powerful gaming engines that are available. To me that is more fun than trying to monkey around with Windows PowerShell to do something it really wasn’t designed to do.

Will all this change in the future? I think perhaps so, because Windows PowerShell 5.0 will have classes. I think that will simplify some aspects of Windows PowerShell. Windows PowerShell becomes more like a real programing language with each new version. So who knows…

As I learned when I was a kid, use the best tool for the job. For example, when I was a kid I used a hammer to crack open walnuts. What I ended up with was more like a rather flat, small, walnut pancake. After that, I looked around for the nut cracker, which I found in the kitchen instead of in my dad’s tool box. Yeah, it was fun smashing walnuts with a hammer, but it did not really help me meet my goal of a healthy snack.

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy 

Comments (1)

  1. Tom H. says:

    Great post Ed! You’re spot on in observing that it always helps to use the best tool for the job. I’m still learning Powershell, but hearing thoughts like yours put a lot of issues in perspective.


Skip to main content