I wrote the Monad Manifesto in 2002. I had been working on Monad for over a year at that point and had been relying upon whiteboard conversations and demos in my office to bring people up to speed on what we were doing. That model didn’t scale well and different people need different forms of information in order to get it. In particular, we were originally trying to do PowerShell as a distribute development model where we had a few PMs, a Dev Lead (Bruce Payette) and myself working in Redmond and then the development and test teams working at the India Development Center in Hyderabad India. We had all seen a number of projects fail in this configuration and were dedicated to making it work. One of the things we heard over and over again was the importance of documenting things. I had had a number of conversations with our team in India where everyone shook their heads and smiled and seemed to get it but then the code clearly demonstrated that they had absolutely no clue what I was saying but weren’t telling me that. We tried a number of times to get very precise in our documentation but time and time again, it was clear that they just weren’t getting the concept so I decided to “go meta” and explain it in a Manifesto.
Writing the Manifesto was difficult. I knew what we needed to do and could come up with examples and explain this point and that point but I had not taken the time to put in words. I had no grand overarching narrative. Sometimes you just need to “say it”. When you are forced to actually “say it”, you’ll often find that you really just sorta understand it – that you have a vague notion of what you mean but you don’t really know what you mean until you are forced to say it. BTW – this works in the other direction as well. Sometimes I’ll be in a meeting where someone is saying something that sounds good and everyone is grooving on it but then I realize that I don’t really know what the person is actually saying and I’m not sure that they do either. I find that everyone benefits from stopping the conversation and asking them to precisely articulate the thought. “Why would that be a good thing?” “Who would use that?” “How would that actually work?” It is hard to ask these questions because they sound stupid – they make you look like you’ve lost the thread … until there is no answer or the answer is fuzzy. The world is completely different (and better) when you are forced to actually “say it”. Clarity provides true context that people can actually agree or disagree and more importantly, can provide clear feedback to make the thinking better. Wooly thinking makes people feel good but doesn’t really move the ball forward. Clarity is progress’s best friend.
The Monad Manifesto forced me to be clear about what problem I was addressing, what my principles were, how I intended to address the problem and then who would benefit and why. One of the most helpful parts of this process was Section 10 Value Propositions. I was lucky enough to work for superstar Israel Gat at Digital and then was able to recruit him both to Tivoli and to Microsoft. Boy did I learn a lot from that guy. One of the most important things he taught me was the Geoffrey Moore Value Propositions format which I use in section 10. What you do is to generate a set of statements of the form: For <Customer> who <Qualifier>, <Product> <Value Statement>. Unlike <Alternative>, <Product> <Differentiator>. Israel explained that it was deceivingly simple and yet exceedingly difficult but that you MUST do it because when you succeed then you have absolute clarity about what you are building, why you are building it and you have a context for prioritizing your work and knowing when a feature cut is acceptable and when it is intolerable. That was some of the best advice I’ve ever received. After I figured out the Value Propositions, I had absolute clarity of what was important, why it was important and was able to bring that clarity to bear on the thousands and thousands of decisions that we made in the project. It also set the overall tone for the project – we are going to succeed based upon delivering compelling value to customers. It is all about the customer, it is not about us, not about technology, not about Microsoft, it is all about customers with real problems and our ability to deliver real value to those customers because we have a clear understanding of those problems and a unique and powerful approach to addressing them. We often get feedback that the PowerShell team is one of the most customer-focused teams and I’d like to think that some of that comes from the clarity of our mission.
It has been over 9 years since I finished V1.2 of the Manifesto and I am amazed when I compare it against the history of Windows PowerShell. Release after release, the vision articulated in the Manifesto has been implemented. For instance, Section 8 describes remote execution:
A script can be executed in BestEffort or Reliable mode. BestEffort scripts are run from the existing process and if that process terminates, no effort to clean up the remote scripts is done and any outstanding results are lost. Reliable mode scripts are persisted to a local SQL store and a service handles the execution of the script. The user can log of out the machine and the service continues to process the script. The user can log back in and get the results of that job sometime in the future.
BestEffort scripting was delivered in PowerShell V2 and the description of Reliable mode scripts pretty much describes how the PowerShell V3 workflows work. I published the document in 2002 and then didn’t read it again until many years later when we were getting V2 out the door when I read it again and was stunned by how accurate it was.
It is only fair to point out where the Manifesto has not been implemented or implemented well. With PowerShell V3, the new admin GUIs ARE layered on top of PowerShell but most of them do not emit the command line equivalents (the AD GUI does). I also stated that 50-70% of a generic management GUI tool could be provided for free by building the right type of Cmdlets. We have not delivered that but if you take a look at what we are doing with the V3 Show-Command and consider what you would have if you combined that with something like PowerGUI, you can see that we are getting close.
To borrow a phrase from Buddha: drop by drop, a bucket is filled.