Reflections on the PowerShell Scripting Games

talkbubbleDuring the most recent PowerShell Scripting Games, I was fortunate enough to be one of the judges. Now that the games have concluded I thought I’d share my reflections on the entries. Naturally these are merely my opinions but they are drawn from years of experience with PowerShell and almost 25 years as an IT Pro. All I can hope is that you’ll consider some of these things on your next PowerShell development project.

Let me also be clear, for those of you still new to PowerShell, that when using it interactively at a PowerShell prompt, anything goes if it helps you get the job done efficiently. But when you are creating a scripted PowerShell solution, something that will live on, then the guidelines are a little different.

It is true that the challenges for this past set of games were complex. Frankly, I’m not sure how I would have even started on a few of them. That said, we’re still talking about PowerShell scripts in the end. One thing that struck me on the entries I judged, was how often I felt I was reading source code for a Visual Studio project and not a PowerShell script. On one hand that could be considered a good thing: PowerShell is flexible enough to create anything from basic scripts to the types of entries I reviewed. But then again, if you have the technical chops to come up with code like I read, you probably could create a “real” set of compiled tools. At some point in your development process you might ask yourself if you are creating a PowerShell script or have moved beyond and maybe a script isn’t the right solution. Yes, the game entries needed to be PowerShell scripts and modules but what about what you’re working on?

Even so, this brings me to my next point: maintainability. The best way to test this is to hand your script files to someone else, ideally with a little less PowerShell knowledge than you, and see if they can understand what your scripts do and how. Many of the entries I read were sprawling, complicated masses of functions and scripts and .NET code. I was challenged in many cases to try and figure out what was going on. If *I* have to struggle to figure out how all the pieces of your script or module work, think about your co-worker who gets handed your solution to maintain or troubleshoot when you get promoted. Or it might be you coming back to it in 6 months.

There is no penalty for comments. I encourage beginners to write the comments first so that they can organize and plan their work. For a module, you can also write your own About help topics. In my opinion, information like this is just as important as the PowerShell commands you are using.

Lastly, I have the usual concerns about syntax and language choices. Yes, I know there are always exceptions. Don’t resort to using .NET classes when a cmdlet will do. Use standard verbs and meaningful nouns in your command names. But perhaps the biggest peeve for me is the continued use of the Return keyword.

Whenever I see the Return keyword, I feel the script author has not fully grasped the PowerShell paradigm. To my way of thinking we don’t return values we write objects to the pipeline. The only time I use Return is when I intentionally want to bail out of a script or function and gracefully terminate everything. Usually when I see the use of Return I also see a lot of unnecessary helper functions each intended to “return” something. This only adds to the (unneccessary) complexity of your work. Add in a lack of documentation and you have a mess of, let’s call it, sub-optimal PowerShell.

A well-crafted PowerShell script file can be a thing of beauty.

The pipeline opens,
objects blossom sending joy
formatted as bliss

What do you think? What have you seen in your company or in the wild that is good, bad or ugly?

Scripting Games 2011 Notes from the Field

I’ve been making headway in reviewing and judging entries in the 2011 Scripting Games. I know there has been a lot of discussion about the lack of comments and I’m doing what I can with entries I judge, but I’m not guaranteeing anything. What I will do is put down some overall comments and impressions that I hope you can use for the remaining events. Continue reading “Scripting Games 2011 Notes from the Field”

PowerShell Picasso


You have probably heard the story (or legend) about Pablo Picasso and his napkin drawing. A guy goes up to Picasso in a cafe and asks for an autograph or something. Picasso sketches out something in a minute or so. He turns to the guy and says, “That will be $10,000".”  The guy is stunned and replies “It only took you a minute!”. To which Picasso replies, “Yes, but it took a lifetime of experience.”

By now you’re wondering what this has to do with Windows PowerShell. Well, the reason Picasso could create a masterpiece in minutes on a napkin was because he already knew all the rules and knew how to apply them in the most efficient manner possible. Because he already knew “the long way” to do something, he was able to take a “shortcut”. I’m simplifying a bit to make my PowerShell analogy so stick with me.

Continue reading “PowerShell Picasso”

Profiling a Script

Last summer, Ed Wilson was looking for help with a small part of the book he was finishing up, Windows PowerShell 2.0 Best Practices. The topic he was working on was, “How do I know this script is safe to run?” Which is a great question and one with greater significance as more administrators come to PowerShell and are tempted to run scripts created elsewhere while not having perhaps all the experience and training to fully appreciate what might happen. I offered some comments on some things I would do. I also decided to write a script (trust me) that an administrator could run that would analyze a PowerShell script and produce a report, or profile, for that script.

Continue reading “Profiling a Script”

Absolute Beginning PowerShell

powershell2xa4 I was looking at my current Mr. Roboto column “Polish Your Shell” on learning PowerShell by starting with 3 basic commands and noticed a lengthy and serious comment. I’ve always felt PowerShell is easy to use and learn, which was the point of my column.  However, the comments paint a different story and one that I feel is more pervasive.

I’m afraid the comment is representative of how PowerShell is perceived by many IT admins. They don’t have time to learn anything new or their hair is constantly on fire (to borrow a favorite Jeffrey Snover phrase). Even though the concepts of cmdlets, parameters and a pipeline seem easy and practically self-apparent, they are not. Especially for an administrator who has never had to open a command window before. Granted GUI-based admin tools might have been cumbersome, but at least you could make some educated guesses about how to use it. A command line is very different.

Many of us in the PowerShell community have been involved with PowerShell for so long that I think we forget, I know I do, sometimes what the experience is like the first time you see a PS prompt.  So what’s my point?

First, if you are a PowerShell professional, don’t forget what it was like the first time you saw a PS prompt. What can you do to help administrators learn, adopt and embrace PowerShell?

Second, how did you first approach using and learning PowerShell? Did you buy a book or take a class? Did you read the user guide? Did you even know there is a user guide? Do you have any newbie best practices?

Finally, I hope you’ll take a minute to read the original Mr. Roboto comments and let me know what you think.  Is he right? Do you agree? Disagree? Are there directions you think Microsoft should take for future PowerShell versions?

PowerShell is here to stay and is only going to spread further into your datacenter. How do we make this process as easy and painless as possible?