<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>Duff</author><text>My favorite thing like this for a purely technical topic was a project where there was a mandatory requirement to NOT support ethernet auto-negotiation.&lt;p&gt;Why? The company had a long-standing policy of manually setting speed and duplex to ensure that there were no duplex mismatches. The was a team of 6-7 people who would audit servers and check switchports, and they produced a report was issued every week, and reviewed by the CIO and other luminaries. People would be shamed for errant configurations, as only the auto-negotiation team could configure NICs.&lt;p&gt;The director who controlled the auto-negotiate squad was politically powerful, and got all sorts of power out of it -- including banning GigE. As late as 2010, this org was deploying dozens of 100MB NICs to ESX hosts to get sufficient bandwidth. They also purchased 100MB NICs for desktops.</text><parent_chain><item><author>roc</author><text>Let me tell you why you don&apos;t see this happening more often.&lt;p&gt;I did this on a project a few years back. I replaced a paper workflow process that was taking up two people each in three departments with a web-based workflow that increased visibility, dropped turn-around time from days to minutes, increased accountability and accuracy and trimmed those 16 person hours of processing down to 1-2 per department.&lt;p&gt;Everyone who directly interacted with the new system loved it. Numerous edge cases that would have been lost in high-level review were caught and integrated from day 1 due to my actually watching people do the job for a day or two per department.  The solution has been rock solid (minor maintenance only) for five years.&lt;p&gt;And I almost lost the job.&lt;p&gt;The people who sign the checks were furious.  The balance of political power between departments were thrown for a loop. One head in particular treated the thing as a near-existential threat.  His entire concept of his job revolved around being the authoritative interface for retrieving and maintaining pieces of data that were no longer exclusively under his control.  Another flipped out because middle management saw the results as cause to reduce his headcount and budget, and thus importance.&lt;p&gt;These two departments fought for months, refusing to contribute their shares of budget that were pledged toward modernizing this system.&lt;p&gt;On a technical and practical level, it was the single best experience I&apos;ve ever had as a consultant.  On a personal and economic level, is was one of the worst.  It was some of the hardest money I&apos;ve ever tried to collect.  It was some of the most time and energy I&apos;ve put into the political and &apos;sales&apos; side of a job (the part I treat as a necessary evil, but very much evil).  The corporation has made out like a bandit in the long run.  But I paid the price.&lt;p&gt;It&apos;s simply too easy and financially rewarding to allow a client&apos;s political nonsense to screw up every stage of a project.  I have less stress, the people who pay me are happier and I bill far more hours.&lt;p&gt;As with most software, internally developed software included, you don&apos;t see better projects more often because the incentives are horribly perverted and stacked against it.</text></item><item><author>giberson</author><text>Here&apos;s what I would like to see from a consulting company for once. Don&apos;t interview the stake holders of the company, they don&apos;t use the software like their employees do. They have a high level overview based on feedback from their employees. When you interview them, you&apos;re getting second hand information that will likely be missing key points that they forgot to mention or just simply think is obvious and doesn&apos;t require mentioning.&lt;p&gt;So here&apos;s what you should do. Over the shoulder review of a representative employee of each department. HR, AP, AR etc. Actively watch and understand the processes they go through. FOR AN ENTIRE 8 HOUR SHIFT.&lt;p&gt;No, seriously.&lt;p&gt;Now, you&apos;ve got a good idea of how its done current.&lt;p&gt;Then do the stake holder interview to find out what they want to do differently.&lt;p&gt;Then plan, develop and deploy your software.&lt;p&gt;I seriously don&apos;t get why despite there being a recognized need for understanding the problem scope which everyone one will invest hours in meetings and conference calls talking about, no one actually invests any (significant) time doing, or reviewing the actual process. It&apos;s the fastest most efficient way to understand the problem. It would totally diminish months of back and forth &quot;here&apos;s what you asked for&quot; &quot;no, that&apos;s not what I asked for&quot; development review process that almost _always_ occurs with consultant projects.&lt;p&gt;/rant</text></item></parent_chain></comment><story><title>We&apos;ve invented waterfall</title><url>http://epicenterconsulting.com/method</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>theorique</author><text>Great anecdote that illustrates this principle observed by Upton Sinclair:&lt;p&gt;&quot;It is difficult to get a man to understand something when his salary depends on his not understanding it.&quot; (from &lt;i&gt;I, Candidate for Governor: And How I Got Licked&lt;/i&gt;)</text><parent_chain><item><author>roc</author><text>Let me tell you why you don&apos;t see this happening more often.&lt;p&gt;I did this on a project a few years back. I replaced a paper workflow process that was taking up two people each in three departments with a web-based workflow that increased visibility, dropped turn-around time from days to minutes, increased accountability and accuracy and trimmed those 16 person hours of processing down to 1-2 per department.&lt;p&gt;Everyone who directly interacted with the new system loved it. Numerous edge cases that would have been lost in high-level review were caught and integrated from day 1 due to my actually watching people do the job for a day or two per department.  The solution has been rock solid (minor maintenance only) for five years.&lt;p&gt;And I almost lost the job.&lt;p&gt;The people who sign the checks were furious.  The balance of political power between departments were thrown for a loop. One head in particular treated the thing as a near-existential threat.  His entire concept of his job revolved around being the authoritative interface for retrieving and maintaining pieces of data that were no longer exclusively under his control.  Another flipped out because middle management saw the results as cause to reduce his headcount and budget, and thus importance.&lt;p&gt;These two departments fought for months, refusing to contribute their shares of budget that were pledged toward modernizing this system.&lt;p&gt;On a technical and practical level, it was the single best experience I&apos;ve ever had as a consultant.  On a personal and economic level, is was one of the worst.  It was some of the hardest money I&apos;ve ever tried to collect.  It was some of the most time and energy I&apos;ve put into the political and &apos;sales&apos; side of a job (the part I treat as a necessary evil, but very much evil).  The corporation has made out like a bandit in the long run.  But I paid the price.&lt;p&gt;It&apos;s simply too easy and financially rewarding to allow a client&apos;s political nonsense to screw up every stage of a project.  I have less stress, the people who pay me are happier and I bill far more hours.&lt;p&gt;As with most software, internally developed software included, you don&apos;t see better projects more often because the incentives are horribly perverted and stacked against it.</text></item><item><author>giberson</author><text>Here&apos;s what I would like to see from a consulting company for once. Don&apos;t interview the stake holders of the company, they don&apos;t use the software like their employees do. They have a high level overview based on feedback from their employees. When you interview them, you&apos;re getting second hand information that will likely be missing key points that they forgot to mention or just simply think is obvious and doesn&apos;t require mentioning.&lt;p&gt;So here&apos;s what you should do. Over the shoulder review of a representative employee of each department. HR, AP, AR etc. Actively watch and understand the processes they go through. FOR AN ENTIRE 8 HOUR SHIFT.&lt;p&gt;No, seriously.&lt;p&gt;Now, you&apos;ve got a good idea of how its done current.&lt;p&gt;Then do the stake holder interview to find out what they want to do differently.&lt;p&gt;Then plan, develop and deploy your software.&lt;p&gt;I seriously don&apos;t get why despite there being a recognized need for understanding the problem scope which everyone one will invest hours in meetings and conference calls talking about, no one actually invests any (significant) time doing, or reviewing the actual process. It&apos;s the fastest most efficient way to understand the problem. It would totally diminish months of back and forth &quot;here&apos;s what you asked for&quot; &quot;no, that&apos;s not what I asked for&quot; development review process that almost _always_ occurs with consultant projects.&lt;p&gt;/rant</text></item></parent_chain></comment><story><title>We&apos;ve invented waterfall</title><url>http://epicenterconsulting.com/method</url></story>