I'm Andy Warren, currently a SQL Server trainer with End to End Training. Over the past few years I've been a developer, DBA, and IT Director. I was one of the original founders of SQLServerCentral.com and helped grow that community from zero to about 300k members before deciding to move on to other ventures.

Back in July we had Chad Miller visit oPASS to do a presentation on Powershell. It was well received and kudos to Chad for a nice presentation and taking the time to drive up from Tampa. Going in to the presentation I would say my view of Powershell was interesting, but over hyped, but then again, I’m typically not a bleeding edge adopter of technology either.

Chad made some interesting remarks during the presentation (and apologies if I put words in his mouth by accident):

SQL Server people “get” scripting faster than others do in his experience. He attributes that to the fact that so much of we do are scripts already. Syntax is different, usefulness of the concept is already engrained

Believed that Powershell was powerful because it took relatively few lines of code to do complex tasks

Ease of discovery of properties/methods makes it easier to learn

He’s looking forward to the day when presentations are less about the basics and more about solving real problems with it

The first one sounds plausible. The second – I think – is over stated. I’m sure there is a limit, but verbosity of code has never struck me as a major impediment to getting things done. Of course, that assumes more than passing comfort with the syntax. I’m probably also biased, as many C# people consider VB.Net to be verbose, but I find VB.Net to be reasonable. In both cases it’s the difference between code you really write and pre-packaged/reusable code that impacts productivity. On the third one I agree about 50% – PS does make it easy to discover, but so does the Visual Studiio IDE, either via the object browser or via the immediate window. Calling it 50% is probably unfair, because I think easy of discovery is critical to learning any new product. The last point was really great, until we build that shared knowledge it’s hard for anyone to move into deeper areas. Interesting to see how (if) this moves forward in the next couple years.

I’ve done my fair of scripting and batch files over the years, ranging from almost vanilla batch files to more advanced ones using things like PC Magazine Batchman (best link I could find), VBScript, and just a small amount of PS work so far. Scripting is a useful technique, but once I moved into “real” programming environments I found that going back was hard. Even VBScript scripts I’d write in VB6 for the intellisense, debugging, etc, and then as a final step make it a true VBScript file. I’d say in many ways that a very nice IDE trumps all, for learning and pure efficiency. The Powershell IDE seems like a useful step in that direction, but note quite all the way there.

Some of us will need PS at work, others may never need it. As SQL professionals I think we need to know the basics; what is Powershell, how to load and run a script, the basics of variables and comments. After that you make the decision about where to spend your very limited professional development time – do you learn more PS, Analysis Services, or even something else? No wrong answer.

For those that really enjoy Powershell, I’d suggest taking one more step and trying a “real” language, something that has a first class IDE, supports all the concepts that go into programs today. A good way to do this is with SMO (SQL Management Objects) to build a first class UI around some solution you need. You can call SMO from PS of course, but if you want something really sophisticated, use Visual Studio or similar. Make sure you learn how to use source control either way, and to put good comments in – because even something as small as a batch file can end up being a key part of the enterprise strategy.

It proved to me (again) that I’ll always enjoy hearing about a topic from someone who is both passionate and knowledgeable, someone that has put some effort into making it do tricks.

Comments

Posted by Anonymous on 24 September 2009

Posted by Steve Jones on 24 September 2009

I tend to agree with you other than to say if PS becomes a big part of use in the product, then it may be worth learning. MS is pushing it, but until we see it in more scripts, samples, installations, etc., I'm not diving in with both feet.

I've always been more of a scripting person, but I think some of that comes with history. I wrote lots of batch files to accomplish things in the pre-Windows days, and lots of shell scripts in *Nix way back when. So I'm happy with a reference manual and a text editor.

Posted by Anonymous on 24 September 2009

Thank you for submitting this cool story - Trackback from PimpThisBlog.com

Posted by AllenMWhite on 24 September 2009

Andy, I have to disagree (and not only because I speak/write about PowerShell.

When I started speaking the topic was SMO. It was new (this being 2005/2006) and I was excited to use it to build code to manage SQL Server MY way. My examples were all in VB.NET. As I presented it to audiences I received immediate push back because many of them were not allowed to have Visual Studio on their desktops. Once I switched to PowerShell, providing the same interfaces, the reception was great.

DBAs are administrators, not developers, and PowerShell is a much more appropriate platform for their automation tasks.

Allen

Posted by Andy Warren on 24 September 2009

Allen, you may well be right. I'm just not there yet. Wouldn't most admins already have 90% of VS in the form of BIDS and SSMS? It the problem licensing (cost), perceived security risk, perceived (or real) complexity, or ?

Posted by cmille19 on 24 September 2009

Thanks, I enjoyed presenting and discussion we had afterwards. I've had a chance to think about the fewer lines of code case I presented. I noticed a good blog post entitled "Brevity is Not Power", pl.atyp.us/wordpress that brings up an interesting point. It's not fewer lines of code, but rather whether the language is better at showing what the code does to another programmer. If you replace programmer with IT Pro (DBA) and language with Powershell, the question becomes "Does Powershell more clearly express the intent of the code than C# or VB.NET to an IT Pro." I think you know my answer.

As for an IDE, I would agree Visual Studio is very rich and powerful with intellisense and testing features (and complexity) that Powershell does not have. However, Powershell provides a different development model, one that is even different VBScript. Since Powershell is still a shell the development of scripts starts out at the command line interface (CLI). The CLI makes it easy to play with code, discover classes and methods of objects without writing a full script or program. The use of command line intepreter is not a new concept and is used by other dynamic languages, see dobbscodetalk.com/index.php.

Demo-ing the Powershell development process would make a nice longer post.

Your point about .NET folks already familar with C#/VB.NET and Visual Studio is very true, however I would say that's not the case for most IT Pro's. They don't know VS, C# or VB.NET. I could train someone in Powershell and command-line and make them productive much faster than C# and Visual Studio.

Coming from the other direction, as someone more familar with Powershell than C#, I find learning myself digging into SVN, WPF, LINQ, NUnit and XML because I want to do more with Powershell. And that's really interesting, if it weren't for Powershell I don't think would have invested the time to learn these things. And should I want to write C#, the jump from Powershell to C# is more of a gentle step than a giant leap.

Posted by Andy Warren on 24 September 2009

Chad, the link about brevity was good and interesting, thanks for sharing that. When it comes to CLI vs UI, that's almost a religious debate. I don't think there's a right answer, but I'd guess that someone with a CLI background will tend towards CLI tools? On the other hand, someone that is truly new I'd guess would benefit from the UI. Even in SQL I use a mix, there are times when a richer toolset helps me work beyond pure discovery.

Reduced training time to be productive is compelling. I'm not sold, but I can see where it could be true. Don't have to get OOP to use objects in many cases. I think it's the best argument, becuase for many DBA's it would be worth a day to learn it, but perhaps not a week.

Nunit is a beautiful thing! If Powershell leads more DBA's to code, that's also compelling. Not that they need to be hard core developers, but understanding how and why developers build solutions can really make a difference in how we see them, and how we help them.