Scorecarding My 2009 Resolutions

A year ago I broke my habit and made a set of News Years resolutions and then published them on the team blog HERE.  Lee Holmes suggested I go back and review how I did on those.  Glug!  Let’s give it a go:

1. Ship a great PowerShell V2, WSMAN, BITS, WMI, and Server Manager with W7 & WS08R2.
• Nailed it.  I am super happy with what we delivered in W7 and WS08R2.  You like to say that “no one cares about your first million lines of code’ but they then allow you to write a couple hundred (or thousand) lines of code and deliver amazing functions.  The stuff we delivered really proved that point.  I am absolutely amazed but the amount of functions were are able to deliver.  I need to quickly add:
1. We still need more.  We are digging ourselves out of a 30 year hole and that takes a while.  Still, I think we and our partners (within the company and in the industry) have delivered enough that it delivers critical mass of functions such that it makes sense for all but the lowest skilled/lowest ambition admins (the people that will eventually leave IT to start a band, work as a hair stylist, or work the drive-thru window at a fast food restaurant) to jump on board and use the technologies.
2. I talked to an PowerShell MVP recently who said that with V2, they no longer felt like they knew everything about PowerShell.  My response was that given how much we delivered in V2, no one knew everything about PowerShell anymore – not me, not Bruce, not Lee – no one!
3. We delivered a ton of new code that we can do the same trick for the next version of the technologies.  We are in the process of working on the next version of  Microsoft BaseLine Configuration Analyzer (MBCA).  You’ll have to wait a while to hear the details but let me say this – we were able to do the trick of writing a small amount of code to stitch together what was already there to deliver mind-bending results.  The future looks VERY bright!
2. Bundle PowerShell V2, WSMAN, and BITs into a single management platform download that supports downlevel machines.
• Nailed the delivery.  This topic deserves a blog entry all of by itself.  We delivered the Windows Management Framework for XP and above.  You have NO IDEA how difficult this was to do.  A few of us have been trying to do this for over 5 years!  
• Weak on the rollout.  We did a poor job of rolling this out.  We announced it via a set of blog postings without any real marketing/evangelization push.  We gave it a new name (which was the right thing to do) but without marketing the awareness of this new name, it has lead to confusion.
3. Encourage the industry adoption of WSMAN by educating people on the value of the protocol and PowerShell's use and support for the protocol.
• Mixed.  I think we’ve done a reasonable job delivering and communicating our support and usage of WSMAN.  I think that PowerShell’s support of WSMAN is the critical element here because it means that device vendors can immediately benefit by implementing WSMAN agents.  In the past, these vendors had to wait for the management products to support the new protocol (and then wait until customers bought that new generation of products) before there was any payback on their investment.  Because PowerShell V2 has a set of WSMAN cmdlets, IT pros can write scripts to manage these new devices.  That said, we have more work to do to fully support the latest version of the standard.
4. Encourage the writing of WMI providers by educating people on the value of WMI and PowerShell's support for WMI.
• Poor.  We improved the PowerShell experience of working with WMI which dramatically increased the value of writing WMI providers.  I don’t think we have done a good job communicating this.
5. Encourage the community to write and share PowerShell scripts and educate them on the features we put into V2 to make this easier/better.
• Mixed.  On the plus side we delivered a number of features (like Modules, comment-based help, etc) that make it easy to deliver and share high quality scripts and I think we’ve been very consistent and clear about communicating the need for the community to work together to share scripts.  There are a number of script sharing sites but I don’t have a good feel for how much IT Pros are using them.
6. Seek out complainers and listen carefully for what we should be doing better.  Encourage people to tell us when and where we screw up.
• Great.  Our heads and our hearts are in the right place on this one.  We do a good job encouraging people to tell us when and where we need to do better and listen to this input without our egos getting in the way.  I’ve never worked with a team so open to tough feedback.
• That said, we understand the difficulties caused by having to respond to this feedback on the Windows release cycle.  That is inescapable cost of ubiquity.
7. Get us on a plan to deliver solutions on a faster pace then OS releases.
• Fail.
8. Figure out the right long-term architecture for the optimal integration of PowerShell, distributed job scheduling and workflow.
• In progress.  If I was being hardcore, I’d give myself a FAIL on this because it isn’t figured out yet.  That said, we’re working on it and I’m really happy with the direction so while there are no promises - watch this space.
9. Figure out the right mechanism for Rich Internet Applications (RIAs - e.g. Silverlight or AJAX apps) to talk to PowerShell across the web.
• Fail.  Watch this space.
10. Promulgate the benefits and techniques of metaprogramming using PowerShell.
• Mixed.  I don’t think we have done a good job educating people on the power of PowerShell.  That said, I did contact Jaykul and showed him how to use some metaprogramming for PowerBoots to reduce the coding required by maybe an order of magnitude.  He did a great job running with that.  We just need a couple hundred more examples.
11. Develop or encourage the development of one or more PowerShell-based GUI scripting libraries (ala TK).
• Success.  I’m pleased to see both PowerBoots and WPK in this space.  Both of these efforts are awesome and show what I knew was going to be the case – Scripting GUIs in PowerShell is going to ROCK!
12. Ensure that everyone knows how easy it is to develop Delegated Web-Based Self-Service Portals using PowerShell.
• Mixed.  Ok – as read – it should be “Fail” because I said “everyone” and that is clearly not the case.  That said, this was the highlight of my talk at TechEd and we had an entire session on this at the PDC so we are getting the story out there.  We have Exchange which is using this model in production and we have at least one other large server product using this (but not discussing it publically). 
13. Ship our internal Cmdlet Designer tool so that everyone can design large sets of Cmdlets in a consistent coherent fashion.
• Success.  We shipped this in Oct.  The announcement is HERE.  Sadly I haven’t seen much feedback on it.

All and all, I’m very happy with the year but there are still lots of opportunity to improve.

Experiment!  Enjoy!  Engage!

Jeffrey Snover [MSFT]
Distinguished Engineer
Visit the Windows PowerShell Team blog at:    http://blogs.msdn.com/PowerShell
Visit the Windows PowerShell ScriptCenter at:  http://www.microsoft.com/technet/scriptcenter/hubs/msh.mspx