Driving Powershell adoption at the workplace

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!