How to approach and prioritize technical debt
&gt; I&#x27;ve seen some managers (engineering and product alike) say phrases like, &quot;well, if you created a better solution in the first place, we wouldn&#x27;t be in this situation&quot; – this is just stupid, inhumane, and ultimately pointless<p>This is such a disappointing aspect of the &#x27;technical debt&#x27; concept and surrounding discussion.<p>The unspoken truth is that technical debt is most often a euphemism for inexperience and lack of skill. This may be an uncomfortable truth but it doesn&#x27;t have to be inhumane. It&#x27;s not inhumane to identify a lack of skill and then address it.<p>The problem with &#x27;technical debt&#x27; you&#x27;ll won&#x27;t find a concrete definition, and you won&#x27;t see a consistent usage across the board. It is far more used as a way for engineers to posture as if &quot;we meant to build it that way&quot;, we were making an explicit cost-benefit tradeoff... spend more time or get it out quickly.<p>Take an engineer who ostensibly &quot;intended&quot; to accrue some technical debt. Ask them to fix said debt and note that you&#x27;ll find more debt accrued.<p>The fallacy behind &#x27;tech debt&#x27; is that it assumes as an axiom that continuously building a robust system is really just a matter of time spent -- and otherwise has little do with experience and value set.<p>But this incorrect. How much upstream scope&#x2F;features delivered is certainly a function of time. Feature&#x2F;Capability X, Y, Z will take more time than X and Y alone. But building a system with a fixed set of value in a robust and decoupled way is not a function of immediate time available _today_ -- it&#x27;s a function of skill set. Many will balk at this, I realize. Usually it&#x27;s because there&#x27;s a conflation between system &quot;flexibility&quot; and architectural soundness, and a misunderstanding that some code duplication has anything to do with &#x27;tech debt&#x27;.<p>&#x27;Technical debt&#x27; hurts everyone because it doesn&#x27;t admit to any of this, and shifts the buck away from any personal skill issue. So, too frequently the engineer goes back to fix the technical debt and not their own skill set. That&#x27;s why there&#x27;s always a perpetuating game of technical debt over years until the great 7 year rewrite.