{"id":25,"date":"2011-10-01T20:43:24","date_gmt":"2011-10-02T03:43:24","guid":{"rendered":"http:\/\/www.jsnover.com\/blog\/?p=25"},"modified":"2013-09-22T18:02:32","modified_gmt":"2013-09-23T01:02:32","slug":"monad-manifesto","status":"publish","type":"post","link":"https:\/\/www.jsnover.com\/blog\/2011\/10\/01\/monad-manifesto\/","title":{"rendered":"Monad Manifesto"},"content":{"rendered":"

I wrote the \u00a0Monad Manifesto<\/a>\u00a0in 2002.\u00a0 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.\u00a0 That model\u00a0didn’t\u00a0scale well and different people need different forms of information in order to get it.\u00a0 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<\/a>) and myself working in Redmond and then the development and test teams working at the India Development Center<\/a> in Hyderabad India.\u00a0 We had all seen a number of projects fail in this configuration and were dedicated to making it work.\u00a0 One of the things we heard over and over again was the importance of documenting things.\u00a0 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\u00a0weren’t\u00a0telling me that.\u00a0\u00a0 We tried a number of times to get very precise in our documentation but time and time again, it was clear that they just\u00a0weren’t\u00a0getting the concept so I decided to \u201cgo meta\u201d and explain it in a Manifesto.<\/p>\n

Writing the Manifesto was difficult.\u00a0 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\u00a0 words.\u00a0 I had no grand overarching narrative.\u00a0 Sometimes you just need to \u201csay it\u201d.\u00a0 When you are forced to actually \u201csay it\u201d, you\u2019ll often find that you really just sorta understand it \u2013 that you have a vague notion of what you mean but you don\u2019t really know what you mean until you are forced to say it.\u00a0 BTW \u2013 this works in the other direction as well.\u00a0 Sometimes I\u2019ll 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\u2019t really know what the person is actually saying and I’m not sure that they do either.\u00a0 I find that everyone benefits from stopping the conversation and asking them to precisely articulate the thought. \u00a0\u201cWhy would that be a good thing?<\/em>\u201d\u00a0 \u201cWho would use that?<\/em>\u201d \u201cHow would that actually work?<\/em>\u201d\u00a0\u00a0 It is hard to ask these questions because they sound stupid \u2013 they make you look like you\u2019ve lost the thread \u2026 until there is no answer or the answer is fuzzy.\u00a0 The world is completely different (and better) when you are forced to actually \u201csay it\u201d.\u00a0\u00a0 Clarity provides true context that people can actually agree or disagree and more importantly, can provide clear feedback to make the thinking better.\u00a0 Wooly thinking makes people feel good but\u00a0doesn’t\u00a0really move the ball forward.\u00a0 Clarity is progress\u2019s best friend.<\/p>\n

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.\u00a0 One of the most helpful parts of this process was Section 10 Value Propositions.\u00a0 I was lucky enough to work for superstar Israel Gat <\/a>at Digital and then was able to recruit him both to Tivoli and to Microsoft.\u00a0 Boy did I learn a lot from that guy.\u00a0 One of the most important things he taught me was the Geoffrey Moore<\/a> Value Propositions format which I use in section 10.\u00a0 What you do is to generate a set of statements of the form:\u00a0 For <Customer> who <Qualifier>, <Product> <Value Statement>.\u00a0 Unlike <Alternative>, <Product> <Differentiator>.\u00a0 \u00a0Israel 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.\u00a0 \u00a0That was some of the best advice\u00a0I’ve\u00a0ever received.\u00a0 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.\u00a0 It also set the overall tone for the project \u2013 we are going to succeed based upon delivering compelling value to customers<\/strong>.\u00a0 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. \u00a0We 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.<\/p>\n

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.\u00a0 Release after release, the vision articulated in the Manifesto has been implemented.\u00a0 For instance, Section 8 describes remote execution:<\/p>\n

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.<\/p><\/blockquote>\n

BestEffort scripting was delivered in PowerShell V2 and the description of Reliable mode scripts pretty much describes how the PowerShell V3 workflows work.\u00a0 \u00a0\u00a0I published the document in 2002 and then didn\u2019t 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.<\/p>\n

It is only fair to point out where the Manifesto has not been implemented or implemented well.\u00a0 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). \u00a0\u00a0I also stated that 50-70% of a generic management GUI tool could be provided for free by building the right type of Cmdlets.\u00a0 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.<\/p>\n

To borrow a phrase from Buddha: drop by drop, a bucket is filled.<\/p>\n","protected":false},"excerpt":{"rendered":"

I wrote the \u00a0Monad Manifesto\u00a0in 2002.\u00a0 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 … Continue reading →<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"advanced_seo_description":"","jetpack_seo_html_title":"","jetpack_seo_noindex":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[4,5],"tags":[9],"class_list":["post-25","post","type-post","status-publish","format-standard","hentry","category-powershell","category-work","tag-powershell"],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/www.jsnover.com\/blog\/wp-json\/wp\/v2\/posts\/25","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.jsnover.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.jsnover.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.jsnover.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.jsnover.com\/blog\/wp-json\/wp\/v2\/comments?post=25"}],"version-history":[{"count":8,"href":"https:\/\/www.jsnover.com\/blog\/wp-json\/wp\/v2\/posts\/25\/revisions"}],"predecessor-version":[{"id":217,"href":"https:\/\/www.jsnover.com\/blog\/wp-json\/wp\/v2\/posts\/25\/revisions\/217"}],"wp:attachment":[{"href":"https:\/\/www.jsnover.com\/blog\/wp-json\/wp\/v2\/media?parent=25"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.jsnover.com\/blog\/wp-json\/wp\/v2\/categories?post=25"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.jsnover.com\/blog\/wp-json\/wp\/v2\/tags?post=25"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}