<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>mmcnl</author><text>This is not true for agile. The agile manifesto was in fact drafted by software developers. Also, agile doesn&amp;#x27;t prescribe any process at all, in fact, it does the opposite. Agile in essence is quite beautiful, unfortunately it gets twisted and turned upside down until it&amp;#x27;s just another methodology (which is exactly the opposite of its original meaning).</text><parent_chain><item><author>sytelus</author><text>There is an insider story about how these methodologies comes about. So there are few groups of people whose sole job is to do consulting on failed&amp;#x2F;late&amp;#x2F;over budget projects. Mind you, they &lt;i&gt;don&amp;#x27;t&lt;/i&gt; write code but rather they observe how things are going and then prescribe process&amp;#x2F;management improvements (McKinsey style). Once in a while, these folks bump in to terrible projects and whatever they prescribed sometime works like a charm. In that case, they take that prescription on road and advertise the hell out in conferences, magazines, blog posts. Unlike regular developers, they have all the time in the world to do these activities. They write books and give interviews and by the media power of distributing information suddenly they pop out as process gods who knows how to fix any project. Eventually the new things starts to fad, people realize what works in project X didn&amp;#x27;t worked in Y, speaker engagements starts drying out and then these folks need new thing to repeat the cycle.&lt;p&gt;The obvious problem is that these folks prescribing the development process are not active developers. They are not even part of any real project over any long duration. They are in job of inventing and selling processes and handing out management advice as consultants. Whatever they prescribe, might have worked only in specific context and for specific symptoms, usually with huge dose of luck. Next time when you see new process fad, look up the history of originator of this process, what company he is part of, how much code has he written, how he makes money. You will know what I&amp;#x27;m talking about.</text></item></parent_chain></comment><story><title>My 20-Year Experience of Software Development Methodologies</title><url>https://zwischenzugs.wordpress.com/2017/10/15/my-20-year-experience-of-software-development-methodologies/</url></story>
<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>icebraining</author><text>Well, let&amp;#x27;s see:&lt;p&gt;Extreme Programming (XP): created by Ron Jeffries, Kent Beck and Ward Cunningham - all developers.&lt;p&gt;The Agile Manifesto: written by seventeen developers (&lt;a href=&quot;http:&amp;#x2F;&amp;#x2F;agilemanifesto.org&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;agilemanifesto.org&amp;#x2F;&lt;/a&gt;).&lt;p&gt;Scrum: created by two of the seventeen above.</text><parent_chain><item><author>sytelus</author><text>There is an insider story about how these methodologies comes about. So there are few groups of people whose sole job is to do consulting on failed&amp;#x2F;late&amp;#x2F;over budget projects. Mind you, they &lt;i&gt;don&amp;#x27;t&lt;/i&gt; write code but rather they observe how things are going and then prescribe process&amp;#x2F;management improvements (McKinsey style). Once in a while, these folks bump in to terrible projects and whatever they prescribed sometime works like a charm. In that case, they take that prescription on road and advertise the hell out in conferences, magazines, blog posts. Unlike regular developers, they have all the time in the world to do these activities. They write books and give interviews and by the media power of distributing information suddenly they pop out as process gods who knows how to fix any project. Eventually the new things starts to fad, people realize what works in project X didn&amp;#x27;t worked in Y, speaker engagements starts drying out and then these folks need new thing to repeat the cycle.&lt;p&gt;The obvious problem is that these folks prescribing the development process are not active developers. They are not even part of any real project over any long duration. They are in job of inventing and selling processes and handing out management advice as consultants. Whatever they prescribe, might have worked only in specific context and for specific symptoms, usually with huge dose of luck. Next time when you see new process fad, look up the history of originator of this process, what company he is part of, how much code has he written, how he makes money. You will know what I&amp;#x27;m talking about.</text></item></parent_chain></comment><story><title>My 20-Year Experience of Software Development Methodologies</title><url>https://zwischenzugs.wordpress.com/2017/10/15/my-20-year-experience-of-software-development-methodologies/</url></story>