Scott Weinstein's .net blog

Let me first reply to comments from the first post in the series

Chris -

I don't have a ready set link that I use to tell people about Powershell, so for sitting down with them and showing has been far more effective than telling. For instance, my friend Andy, despite cutting his teeth on Unix, Bash, Perl, and Tcl still hasn't installed powershell despite my not so subtle jabs that he's at risk of losing his geek mojo. But when you show it to them people get it pretty quickly. Yes, I have played around with PowerShellIDE and Powershell Analyzer, they're both promising tools.

Locrain -

The navigator is cool, thanks. I can't share the code, it belongs to my employer. But you don't want it anyway, the underlying data store has a habit of turning hardened architects into whimpering basket cases. But in any case, I suspect it's just a matter of time before a SQL Server navigator is developed and integrated into a project like the PowerShell Community Extensions

Jeffrey Snover -

Adoption is uneven, everyone on the team uses the navigation provider to look into the proprietary database, it's just so much easier and more powerful than other methods. The two junior developers don't use powershell much beyond that and the build aliases, I think that's partially a matter of their responsibilities, and partially a matter of culture - they've never used the command line before. On the other hand, one of the senior developers, who has experience as an oracle DBA, is actively adopting powershell for ad-hoc and production scripting.

As for what Microsoft could do to help drive adoption, that's easy.

Create a new console host for powershell.

• The windows console is just awful, and everyone knows it.
• PowerShellIDE and Powershell Analyzer aren't sufficient - they are third party tools, and getting third party tools into large Financial Service companies can be very difficult. They also don't feel right as a console replacement.
• The powershell language and technology is just fantastic, it deserves, no needs, a default interactive environment that's worthy of it.

My dirty napkin design for a new powershell console would be built on top of WPF. It would keep the standard CLI paradigm in use for the last 30 years, and not separate the input area from the output area like powershellide does. It would take advantage of WPF to allow for different fonts of the input and output and help. Be copy and pasteable all over, output would have infinite scroll, zoom-ability, and possibly allow for XAML to be used in defining format specifications.

----------------------------------

And onto the next story of driving adoption...

This past Friday I was having a conversation with Bob, the primary business owner of our application. He's extremely technical and our conversation got onto the subject of report's and data cleanup in the proprietary database. I hadn't told him about powershell or the navigation provider, for a couple of reasons, but mostly I wasn't sure that he would be interested. But this particular conversation basically demanded that I show it to him. I went through the basics. ls, select, where, group, gm. He loved it. So I started talking about some general powershell commands, showed how get-command ps explained that ps was just an alias for get-process.

Me: go on, type in ps
Bob: oh wow, so this shows all the tasks, just like task manager?
Me: Yep.
Bob: [pause] can this list files,.. and who owns them?
Me: I show him ls on the filesystem and get-acl
Bob: I've been looking for something like this for years!

One bit of low hanging fruit for static analysis is when its use as a tool to communicate code quality to others. Too often, when we talk about code quality we're unable to get past the language of aesthetics, and we end up losing credibility. The key is to talk about measurable facts, not subjective opinion.

Last year, our group inherited a large C++ code base that no one wanted to work with. A senior architect of a large global services group thought the code was dreadful, and although he was correct he couldn't express it any better than complaining about the variable names.

They ended up proposing a BDUF solution, where the users wouldn't see any improvement for nine months, at which point, in theory, the entire system would be replaced.

I took a look at the code, it was scary. I ran some Coderush metrics on it, and applied Lattix DSM to it. Some facts emerged

• There were numerous methods over 5000 lines long, and a few over 20,000 lines long
• Cyclomatic complexity averaged in the fifties
• Nearly the entire code base was strongly connected. There were no independent layers.

These were facts that any technical manager could understand - maintenance of this code base would be expensive. But once I knew just how bad the code was, it was a lot less intimidating, and I realized something critical; the code could be maintained, it could be understood, and we could make incremental improvements to it while building a replacement system.

We proposed an agile solution, with the first release available in three months, but without any promises on the timeline for the end-state.

Four months later, phase two is underway, and there's lots of excitement about phase three. The large global services group? They're no longer around.

Next I'll talk about some specific tools and technologies around code reflection and static analysis

A number of months ago, based only on some of the publicly available presentations, blog posts, and some brief experimentation at home, I decided to adopt Powershell, both for myself, and my development team. Initially, I just hope it would be accepted as a better cmd for development. But now we have it running our daily and hourly batch jobs on production servers.

Adoption took some guided effort however, it wasn't nearly sufficient to send out some blog posts showing how cool powershell was. Three different techniques did the trick.

Coercion

As tech lead I had some leeway here, so installing powershell was step 3 in the developer PC setup document. Additionally I went around to each developer and made sure the powershell was installed, and that their profile dot sourced the common team profile.

Other measures included just saying no to any efforts to bring in alternative scripting languages, including cmd, VBScript, and Perl.

Remove barriers to entry

Just like powershell sets up aliases such as cd, ls, and dir so that the environment does what you think it should, the common team profile setup the environment so that .net SDK commands run as expected. I created a bunch of functions and aliases around version control and msbuild, for some quick productivity improvements. 

Typing ccbc is just much easier than

cd c:\d\build\
svn update
msbuild Integration.proj /t:Full

The ccbc alias is so popular that it's entered the everyday vocabulary of the team, as in "did you do a ccbc?"

Make life significantly easier

Our project has to work with a locally developed custom data source, for runtime code we created an ADO.Net provider, but it lacked any interactive query tool, and the range of SQL expressions it accepted was quite limited. Over a weekend I was able to create a powershell navigation provider for the same data source, allowing developers to cd into tables and ls-ing the rows, and filtering the results via 'where'

That hooked 'em!