There is a cool blog over on Windows Live Spaces called PowerShell for Testers. This has a bunch of great technical meat around script testing and testing using scripts. The most recent entry is on Lowering the Cost of Test Automation which makes the case the PowerShell excels at lowering the cost of test automation. I’m very pleased to see this because I strongly believe that at the end of the day, it’s all about economics.
My argument is that there are lots of great technologies but that technologies that matter and endure are those technologies which yield an economic advantage. I like to boast that every architectural element of PowerShell started with economics.
Why do we have a hosting model for Cmdlets? Because it allows us to minimize the amount of code that developers have to write, allows us to provide a huge amount of common functions for free (so developers don’t have to write this code) and because it maximizes the end user experience (which translates into lower learning costs and higher memory retention rates).
Why do we have Namespaces? Because it provides a simple programming model for developers to expose their data stores in a way that can be accessed using a set of common commands and functions (while still allowing them to expose the rich semantics of their store [e.g. it is not a least common denominator model]). This maximizes the discoverability of the namespace while minimizing the learning costs to use the data store.
Why do we pipeline .net objects instead of text? Because it minimizes the amount of code that developers have to write (they don’t have to worry about formatting, sorting, filtering, etc) and because objects eliminate the need for users to parse text to get at the data fields they want to manipulate. This closes the semantic gap between the problem you want to solve and the script you have to write to accomplish the task which lowers initial development costs and on-going maintenance costs.
Why does PowerShell provide a dynamic type system which allows users to rename properties, add properties and methods, etc? Because this provides a simple way for the community to normalize the object surface they have to work with (e.g. remapping properties so everything supports the property “NAME”) which provides a more consistent experience which reduces learning costs and because it makes it allows functions to be associated with the objects they work against so that it is easier and cheaper to manage and share knowledge.
Why does PowerShell provide such a wide range of scripting styles? Because it allows users of different skill sets to use a common tool and form a common community to share scripts and knowledge and because it allows users to easily and incrementally acquire richer and more sophisticated skills and advance their careers thereby.
Why is PowerShell designed to allow GUIs layered on top and its syntax looks more like C# than CMD.exe? Because this model provides a smooth glide path between the GUI, the CLI, various levels of scripting and C#. The GUI teaches the CLI. The CLI educates you about .NET. Scripting prepares you for systems programming. We minimize the effort required for you to advance to whatever skill level you want to advance to.
I could go on all night – there are lots of examples of this in PowerShell.
At the end of the day – it’s all about economics!
Jeffrey Snover [MSFT]
Windows PowerShell/MMC Architect
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