Why PowerShell is important

In his last post of 2006 (the first of 2007 in my timezone, does this guy never sleep?) Jeffry Snover, PowerShell Architect, posted a very good and precise description of why PowerShell is so important. The core of this is the Admin Development Model and I have extracted the most important part here as I think this explains it so good -

One of the things that motivated us to develop PowerShell was the belief that we (Microsoft) had been doing a poor job supporting the Admin Development Model.

All the effort seemed to have gone into treating Admins as GUI-only users or as though they were developers that couldn't handle the complexity of parenthesis. I never quite understood the thinking there. On the one hand, you expect the admin to comprehend the mind-numbing complexity of WMI and ADSI but on the other hand, you invest in a language that allows them to avoid typing the parentheses in an IF statement? Was that really the problem? Don't get me wrong - for what it is, VBScript is great but at the end of the day, a lot of VBScripting is full blown systems programming with a simplier syntax. There is nothing wrong with that. The vast majority of Admins are super smart folks that can do systems programming WHEN THEY HAVE THE TIME TO.

Therein lies the problem. Systems programming takes a lot of time and effort and is pretty formal. The Admins I know don't have a lot of spare time because they run around with their hair on fire. When your hair is on fire, you need a bucket of water and systems programming is not that bucket of water. What admins need is a set of tools that match the reality of their work. Admins need an interactive shell.

An interactive shell that allows them to quickly, easily, and iteratively investigate and manipulate their systems. Since the nature of admin problems/issues change constantly, they need to easily compose solutions by leveraging a set of base, domain-specific, commands and a then set of powerful, domain-independent, utility cmds. Bruce Payette once said something to the effect that, "the lifespan of 95% of the scripts in the world start at the prompt and end at the carriage return".

Once you have an interactive shell that supports great compositional scripting, then, depending upon the problem and the odds that you'll want to do that operation again, Admins save that script into a file and run it instead of having to figure it out/type it every time. Over time, they may decide to generalize the script so that it can deal with more and more situations. Later they may choose to make it more formal and do better error handling. Sometimes, they'll want to make it part of their formal management of production servers at which point they'll want it to be very formal, leveraging types/constraints, rich error handling, digital signatures and all that.

This range of activities, from interactive shell, to quick and dirty scripting, to formal production scripting is what we call the Admin Development Model. (Note that model of work is NOT limited to Admins - many people use this but it is critical for Admins.) PowerShell is very focused on supporting the Admin Development Model. That is why we have an interactive shell.
That is why we struggled hard to find the right balance in our syntax and semantics between interactivity and scriptability. That is why we support
a wide range of scripting styles from quick and dirty (bash-style) scripting to more advanced (Perl-style) scripting to more formal .NET programming. We wanted to ensure that you could learn a single tool and then decide how you were going to use that tool to solve the particular problem at hand.

It is NOT the case that beginners will do the simple stuff and experts will do the sophisticated stuff. We expect everyone will do do everything at some point in time - it is question of the problem they are trying to solve and the skills they have at the moment. (e.g. The highest end of scripters are still going write lots of quick and dirty, ad hoc scripts - because that is the right tool for lots of situations.).

The great thing about having a single tool to do this is that it becomes economical
to invest in learning the capabilities of the tool because it can be leveraged in so many situations. It also increases the pool of people that form the community that help each other solve problems. It also makes it easier to grow your career, as you gain expertise and become more productive and opens up more job opportunities than expertise in a very narrow toolset provides (this is another reason why we leveraged .NET - learning .NET makes you more marketable. If you are a hiring manager leveraging PowerShell - the job is more attractive to people and there is a larger pool of experienced people to hire from.)

PowerShell supports the Admin Development Model because it allows PowerShell to be the right tool for the right job for the maximal range of problems and lays the groundwork for a large and vibrant ecosystem.

- Jeffry Snover