<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>ljm</author><text>I think it &lt;i&gt;could&lt;/i&gt; make more sense if it&amp;#x27;s rephrased to &amp;#x27;all code is a liability&amp;#x27;.&lt;p&gt;Then the equation is simpler. More code = more to maintain = more liability. It says nothing about the quality of the code, just the quantity.&lt;p&gt;Tech debt is a trade-off between near term and long term ambitions - it is literally impossible to build a successful project without accruing this kind of debt, simply because you cannot perfectly anticipate the future. In that sense, it&amp;#x27;s not so much debt as it is a maintenance overhead.</text><parent_chain><item><author>ska</author><text>I think the author is basically diluting the term &amp;quot;technical debt&amp;quot; to the point it becomes meaningless.  Much of what they are talking about is the inherent difficulty of managing complexity, mixed with the difficulty of understanding requirements&amp;#x2F;defining features well.&lt;p&gt;I think &amp;quot;technical debt&amp;quot; as a term is overused and sometimes misapplied, but the core idea resonates with many developers, at least the way it is most often used - which isn&amp;#x27;t exactly the original proposal as another commentpoints out.    The key part of it is the analogy with an interest rate.  I can decide do put  5k on the credit card for a last minute holiday, but for as long as I don&amp;#x27;t pay  that off, I&amp;#x27;m paying 20-something percent, every month, forever.  Similarly for example a rush to add features to hit a demo deadline can introduce brittleness and abstraction failures into your codebase that you pay for every time you make changes, add features, do nearly anything.  The analogy is that some of your development is going to be wasted &amp;quot;servicing the debt&amp;quot; going forward until  you fix that (pay off the debt).  That doesn&amp;#x27;t mean its the wrong move, for the same reasons that taking on debt can be the right move for a person or business.</text></item></parent_chain></comment><story><title>All code is technical debt</title><url>https://www.tokyodev.com/articles/all-code-is-technical-debt</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>Phiwise_</author><text>Absolutely agreed. Articles in this vein rather get my goat, especially because the analogy to real debt is &lt;i&gt;more&lt;/i&gt; clear: If someone wrote a consumer finance article like &amp;quot;All purchases of things other than cans of beans and Certificates of Deposit are like Mortgages, because what if your industry collapses tomorrow?&amp;quot; most people have the good sense to complain that the usually decent advice of saving a bit for a rainy day was being way exaggerated. And yet pieces that run something like &amp;quot;All programming of things other than washing machine microcontrollers are like technical debt, because what if your customer&amp;#x27;s needs suddenly change entirely?&amp;quot; get much more play. Sure, disasters &lt;i&gt;can&lt;/i&gt; happen, and it pays to reserve some resources to be ready for them, but it also pays to use resources when times are good to expand. It seems to me Cunningham&amp;#x27;s point was to &lt;i&gt;encourage a move towards&lt;/i&gt; balance; headlines that don&amp;#x27;t overshoot the mark.</text><parent_chain><item><author>ska</author><text>I think the author is basically diluting the term &amp;quot;technical debt&amp;quot; to the point it becomes meaningless.  Much of what they are talking about is the inherent difficulty of managing complexity, mixed with the difficulty of understanding requirements&amp;#x2F;defining features well.&lt;p&gt;I think &amp;quot;technical debt&amp;quot; as a term is overused and sometimes misapplied, but the core idea resonates with many developers, at least the way it is most often used - which isn&amp;#x27;t exactly the original proposal as another commentpoints out.    The key part of it is the analogy with an interest rate.  I can decide do put  5k on the credit card for a last minute holiday, but for as long as I don&amp;#x27;t pay  that off, I&amp;#x27;m paying 20-something percent, every month, forever.  Similarly for example a rush to add features to hit a demo deadline can introduce brittleness and abstraction failures into your codebase that you pay for every time you make changes, add features, do nearly anything.  The analogy is that some of your development is going to be wasted &amp;quot;servicing the debt&amp;quot; going forward until  you fix that (pay off the debt).  That doesn&amp;#x27;t mean its the wrong move, for the same reasons that taking on debt can be the right move for a person or business.</text></item></parent_chain></comment><story><title>All code is technical debt</title><url>https://www.tokyodev.com/articles/all-code-is-technical-debt</url></story>