<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>WesleyJohnson</author><text>For those of you who think and operate this way, I&apos;m sorry, but this WILL catch up with you eventually. At my last job our sales pitch was &quot;Yes&quot;. I won&apos;t use the word &quot;literally&quot; here as it would be an outright lie, but it was pretty close. Our sales guys went into meetings with the assumption that we could pull off whatever the clients wanted in nearly any time frame they wanted. This was all decided on at sales time without any consultation of the actual development team on capabilities, cost or how long it would take to actually implement. Management would tell the IT/IS department (yes, we had to do both) that it was a show of faith in the abilities of our team and that we should be proud of the fact that sales and management were so confident in us. You know what that is? BS. That is sales &quot;selling&quot; IT. It&apos;s complete and utter BS.&lt;p&gt;Sure, we met those deadlines, we implemented those features and we made small fortunes for the company. But at what cost? The infrastructure starts to resemble Jenga more and more, your spaghetti code becomes harder to maintain, you end up with magic strings, magic numbers, client specific cases and conditions and your start eating into your IT budget by having to hire more programmers to support all of your crappy implementations and more hardware to handle the un-optimized pile of crap you&apos;re running.&lt;p&gt;What&apos;s worse is the very people you rely on to keep this tower from falling over, your programmers who have become so familiar with all the undocumented edge cases of your system, are also the very people you&apos;re basically forcing out. You&apos;re forcing them out because they become tired of not innovating, not refactoring and not progressing the technology OR the business, but instead spending all their time stressing over not &quot;crossing the wires&quot; of this delicate catastrophe. And when you finally lose them as a developer, and you will, it costs you severely in down-time and loses in productivity while you get your other developers and new hires up to speed. But not only do they have to learn the business, they also have to learn all the edge cases that were only known to your senior employee who was finally fed up and quit. And guaranteed, something, somewhere will be forgotten, that wire will get crossed and you&apos;ll pay dearly.&lt;p&gt;And while I do agree that making money and growing the business is the end goal of the business, don&apos;t assume that your IT guy isn&apos;t concerned with that and just wants to write &quot;pretty code&quot;. Often times your IT guys understand the business more than sales, middle management and sometimes upper management because they deal with the logic, the clients, the sales team, and everyone in between day in and day out. When they&apos;re pleading with you to say &quot;no&quot; to a customer or ask for an extension to implement feature &quot;x&quot; properly, maybe you should take heed a little more often. Because the duct taped feature &quot;x&quot; that won over client &quot;A&quot; today, could be the same feature that loses you client &quot;b&quot; and &quot;c&quot; tomorrow because the only developer that new their system well enough to keep them running walked out after being forced to write yet another band-aid.&lt;p&gt;Of course when he quits and everything falls apart, everyone will just assume he was an overpaid, crappy programmer and his buggy code is what was the ultimate cause.</text><parent_chain><item><author>kenjackson</author><text>Unless you&apos;re at a non-profit, revenue/sales/profit are what drives the company.  If you can duct tape a product that gets me $1B of yearly recurring revenue then I will take that over the cleanest architected product that no one wants to pay for.&lt;p&gt;In one of my other comments from a different thread I made the point that a lot of developers don&apos;t realize that they should understand the business.  When you do understand it and the salesperson is in a tizzy about the &quot;wrong thing&quot;, you can point out, &quot;actually, that&apos;s not the real revenue driver.  XYZ is. Why does the customer think ABC is?  I&apos;ll tell you why, it&apos;s because DEF.  But by doing XYZ we can deliver ABC in six months time.&quot;&lt;p&gt;I think you&apos;ll find when you can talk at the level of business a lot of things become clearer for you and the sales team.</text></item><item><author>dkarl</author><text>&lt;i&gt;If you consistently deliver what the business needs most, and you do it well, it’s impossible not to get promoted.  People tell me this isn’t true, that it’s all about the people you know and about “visibility.”  I have no idea how to consistently deliver impactful business results without becoming visible as a side effect.  I hate it when developers ask me how to become “more visible.”  They hate it when I tell them to “do great work.”  They think I’m mocking them.&lt;/i&gt;&lt;p&gt;You can think this way if your idea of &quot;what the business needs most&quot; is &quot;what currently has the sales guys in a tizzy.&quot;  Forget about everything else.  Oh, and if your code only works for current customers, and has to have a bunch of tweaks and fixes applied for each new customer, then people will think your code is what &lt;i&gt;allows&lt;/i&gt; them to sell to new customers.  No kidding.  If you write code that doesn&apos;t handle cases A, B, and C, then later you get credit for adding &quot;support&quot; for A, B, and C and making it possible to sell to customers X, Y, and Z.  That&apos;s &quot;visibility,&quot; because people from sales and marketing will mention your name appreciatively at high levels.&lt;p&gt;And for God&apos;s sake don&apos;t do any work on scaling or reliability, because a salesman never calls up your boss&apos;s boss and says, &quot;It&apos;s been a long time since the scalability of your systems scotched a deal.  I just want to say that&apos;s awesome and thank you.&quot;  Wait until it breaks, make everyone thinks it&apos;s impossible, and then fix it.&lt;p&gt;EDIT:  In a healthy organization, none of this will affect who gets promoted, but in an organization where people worry about &quot;visibility,&quot; this is what they&apos;re talking about.</text></item></parent_chain></comment><story><title>Resignation letter from Microsoft Employee</title><url>http://worldofsu.com/philipsu/?page_id=193</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>anonymous245</author><text>False dichotomy ($1B vs zero).&lt;p&gt;Actually, in my experience, developers understand the business quite well. It&apos;s the other business functions which doesn&apos;t understand development.&lt;p&gt;You &lt;i&gt;WILL&lt;/i&gt; drive out (and keep out) good developers if you fail to treat developers as professionals whose inputs of how to develop software should be respected.</text><parent_chain><item><author>kenjackson</author><text>Unless you&apos;re at a non-profit, revenue/sales/profit are what drives the company.  If you can duct tape a product that gets me $1B of yearly recurring revenue then I will take that over the cleanest architected product that no one wants to pay for.&lt;p&gt;In one of my other comments from a different thread I made the point that a lot of developers don&apos;t realize that they should understand the business.  When you do understand it and the salesperson is in a tizzy about the &quot;wrong thing&quot;, you can point out, &quot;actually, that&apos;s not the real revenue driver.  XYZ is. Why does the customer think ABC is?  I&apos;ll tell you why, it&apos;s because DEF.  But by doing XYZ we can deliver ABC in six months time.&quot;&lt;p&gt;I think you&apos;ll find when you can talk at the level of business a lot of things become clearer for you and the sales team.</text></item><item><author>dkarl</author><text>&lt;i&gt;If you consistently deliver what the business needs most, and you do it well, it’s impossible not to get promoted.  People tell me this isn’t true, that it’s all about the people you know and about “visibility.”  I have no idea how to consistently deliver impactful business results without becoming visible as a side effect.  I hate it when developers ask me how to become “more visible.”  They hate it when I tell them to “do great work.”  They think I’m mocking them.&lt;/i&gt;&lt;p&gt;You can think this way if your idea of &quot;what the business needs most&quot; is &quot;what currently has the sales guys in a tizzy.&quot;  Forget about everything else.  Oh, and if your code only works for current customers, and has to have a bunch of tweaks and fixes applied for each new customer, then people will think your code is what &lt;i&gt;allows&lt;/i&gt; them to sell to new customers.  No kidding.  If you write code that doesn&apos;t handle cases A, B, and C, then later you get credit for adding &quot;support&quot; for A, B, and C and making it possible to sell to customers X, Y, and Z.  That&apos;s &quot;visibility,&quot; because people from sales and marketing will mention your name appreciatively at high levels.&lt;p&gt;And for God&apos;s sake don&apos;t do any work on scaling or reliability, because a salesman never calls up your boss&apos;s boss and says, &quot;It&apos;s been a long time since the scalability of your systems scotched a deal.  I just want to say that&apos;s awesome and thank you.&quot;  Wait until it breaks, make everyone thinks it&apos;s impossible, and then fix it.&lt;p&gt;EDIT:  In a healthy organization, none of this will affect who gets promoted, but in an organization where people worry about &quot;visibility,&quot; this is what they&apos;re talking about.</text></item></parent_chain></comment><story><title>Resignation letter from Microsoft Employee</title><url>http://worldofsu.com/philipsu/?page_id=193</url></story>