<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>thanatropism</author><text>&amp;gt; . Bureaucracy, analysis paralysis, no automated testing, accidental complexity, tech debt, poor retention of experienced developers, poor compensation resulting in sub-par hires, insufficient training and mentoring for new hires etc etc.&lt;p&gt;Most of these look like MBA problems.&lt;p&gt;That said, maybe more experienced coders should be doing MBAs (which isn&amp;#x27;t just about attending classes but about networking, acquiring a wider shallower knowledge base etc) so the dynamics of tech debt are clear to people who are in charge of making debt decisions.</text><parent_chain><item><author>noego</author><text>On the flip side, I&amp;#x27;ve seen far too many teams move at the speed of molasses, for reasons unrelated to the intrinsic complexity of the problem. Bureaucracy, analysis paralysis, no automated testing, accidental complexity, tech debt, poor retention of experienced developers, poor compensation resulting in sub-par hires, insufficient training and mentoring for new hires etc etc. I wouldn&amp;#x27;t be so quick to assume that every single development team is operating at their most ideal.</text></item><item><author>commandlinefan</author><text>What gets me is that software has been a mainstay of modern business for _at least_ 30 years.  And this whole time, every single professional software developer has been telling every single non-software developer the exact same thing, over and over: this takes longer to do than you think.  If, say, 80% of developers were knocking things out, problem free, in an hour or two and the other 20% were hanging back like a 50’s union boss saying, “yeah, that’s going to be an all-day job easy”, then maybe I could understand why they STILL think we’re lying.  Even if 20% of the devs could get things done in the time they seem to think it takes and the other 80% were hemming and hawing I could still understand this perspective.  But that’s not the ratio.  0% of devs can reliably complete tasks in the time that MBA’s seem to think it should take and 100% of devs take longer than they “wish” it would take and THEY STILL AREN’T PAYING ATTENTION.</text></item></parent_chain></comment><story><title>Dear Client, Here’s Why That Change Took So Long</title><url>https://www.simplethread.com/dear-client-heres-why-that-change-took-so-long/</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>novaleaf</author><text>my own anicdata:  Integrate a default proxy into our existing &amp;quot;choose proxy&amp;quot; workflow takes about 2 weeks, and I&amp;#x27;m currently on my 3rd month of those 2 weeks :)&lt;p&gt;Reasons for the delay:&lt;p&gt;1) Proxy is a stand-alone application.  Needs it&amp;#x27;s own deployment and build configuration
2) Main app was running on Node 6.x.   High time to upgrade to 10.x as 6.x LTS is running out.
3) Upgrade to 10.x breaks some modules we depend on (Google Cloud datastore) and that module has been deprecated in Node 8.x+..   time to refactor that....
4) Main app is in a mono-repo with backend systems still running node 6.x   Don&amp;#x27;t want to spend the time upgrading everything to node 10, so need to split Main app into it&amp;#x27;s own repo, decoupling from existing mono-repo codebase
5) Since we are upgrading main app to Node 10, Best to remove dependencies on old definitely-typed typescript typings (upgrade to npm @types definitions).  And as such refactor to use latest version of all modules....
6) Security:  New Default Proxy should only allow the Main app.    code a solution for this using Keypairs....
7)  Docs, sample code for users,  announcement mail.&lt;p&gt;thankfully i&amp;#x27;m currently on step 7.   Usually I expect to be off on my estimates by a factor of 4x.   This is excessive :)</text><parent_chain><item><author>noego</author><text>On the flip side, I&amp;#x27;ve seen far too many teams move at the speed of molasses, for reasons unrelated to the intrinsic complexity of the problem. Bureaucracy, analysis paralysis, no automated testing, accidental complexity, tech debt, poor retention of experienced developers, poor compensation resulting in sub-par hires, insufficient training and mentoring for new hires etc etc. I wouldn&amp;#x27;t be so quick to assume that every single development team is operating at their most ideal.</text></item><item><author>commandlinefan</author><text>What gets me is that software has been a mainstay of modern business for _at least_ 30 years.  And this whole time, every single professional software developer has been telling every single non-software developer the exact same thing, over and over: this takes longer to do than you think.  If, say, 80% of developers were knocking things out, problem free, in an hour or two and the other 20% were hanging back like a 50’s union boss saying, “yeah, that’s going to be an all-day job easy”, then maybe I could understand why they STILL think we’re lying.  Even if 20% of the devs could get things done in the time they seem to think it takes and the other 80% were hemming and hawing I could still understand this perspective.  But that’s not the ratio.  0% of devs can reliably complete tasks in the time that MBA’s seem to think it should take and 100% of devs take longer than they “wish” it would take and THEY STILL AREN’T PAYING ATTENTION.</text></item></parent_chain></comment><story><title>Dear Client, Here’s Why That Change Took So Long</title><url>https://www.simplethread.com/dear-client-heres-why-that-change-took-so-long/</url></story>