Monad Manifesto

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.

12 thoughts on “Monad Manifesto

  1. I’ve said it before, and I’ll say it again. PowerShell is magical. The amount of time it saves me day in, and day out, never ceases to amaze me. I’ve skim-read the manifesto (forgive me, it’s a Sunday! I’ll read it tomorrow) and can only agree with you. This product just keeps getting better and better, and it’s astonishing to read that your ideas for it nearly 10 years ago are still current and implementable.

    To borrow a phrase from my Australian ancestry: bloody ripper!

  2. I’ve been re-reading the Monad Manifesto the last couple weeks while building out PowerShell functionality for a client. I have lifted many of the value propositions (and other points) from the paper and custom delivered them in Stakeholder/Developer/QC & QA meetings to great effect.

    This PowerShell script helped me. My intention was not to turn your template into a mail merge. I wanted to see how the pieces broke down and see them as a whole. This is the first value proposition in the manifesto.

    $Customer = “application developers”
    $Qualifier = “need to expose their administrative functions as command lines and GUIs”
    $Product = “PowerShell”
    $ValueStatement = “provides a highly productive development framework.”
    $Alternative = “building stand-alone command lines”
    $Differentiator = @”
    provides most of the common
    functions including a parser, a data validator/encoder, error reporting mechanisms,
    common functions like sorting/filtering/grouping/formatting/outputting and a set of
    management models which provide common verb sets, error messages and solutions to
    common problems and tools
    “@

    @”
    For $Customer who $Qualifier, $Product $ValueStatement

    Unlike $Alternative, $Product $Differentiator
    “@

  3. One of the best resources, if not the best resource, is when the inventor can articulate the goals of a product to its target customer. Jeffrey, you have tirelessly over the years been able to bring this down-to-earth conversation to the Admins at conferences and in videos. I’m glad that you have a blog platform so that everyone can gain insight into the tool that many of us love so much.
    For the Admins that are just beginning with PowerShell, hearing “Why” is sometimes the only answer they need to understand “How” and “When”

    Congrates on the blog, PowerShell V3, and Server. Can’t wait to see more!

    Jason

  4. Pingback: PowerShell Magazine » An overview of Windows PowerShell features in Windows Server 8 Developer Preview

  5. Pingback: Maximize the reuse of your PowerShell « James O'Neill's Blog

  6. Pingback: Jeffery Snover - Interview With Inventor of PowerShell

  7. Pingback: Interview With Jeffrey Snover – Inventor of PowerShell and Lead Architect for Windows Server 8

  8. Pingback: Interview With Jeffrey Snover – Inventor of PowerShell and Lead Architect for Windows Server 8 | Aleksandar Klisarski's blog

  9. I read post and the manifesto quite a few times and every time I read it, it feels so good. Truly inspirational! Not just the PowerShell related aspects but the way you turned the whole thing into reality.

    Ravi

  10. Pingback: PowerShell Magazine » Are you still thinking about getting started with PowerShell?

  11. Pingback: Steve's Seaside Life › A Manifesto For Experience Design

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>