Technical Debt: Why it'll ruin your software
I&#x27;m being a bit blunt here. It&#x27;s easy to say Technical Debt will ruin your software when you pick a contrived thing and label it as Technical Debt.<p>&gt; John knew his code had a few bugs. But nearing the deadline, another project appeared and it took a lot of John’s time, so he couldn’t go back and fix the problems.<p>This is a problem, but this is not inherently technical debt. That&#x27;s just delivering a bad&#x2F;incomplete feature (Not necessarily John&#x27;s fault if he&#x27;s been asked to make changes). Code with Technical debt works or mostly works, but relies on non-maintainable or less ideal than patterns.<p>Simplified example. Adding a &quot;Cancel&quot; Button to a form. This button involves adding a new &quot;secondary&quot; class style to the button.<p>* Technical Debt - Button is in place. Works correctly. Instead of a &lt;Button&gt; component and tweaking it to handle the new &quot;secondary&quot; class. John simply copies and pastes the &lt;Button&gt; code directly into the implementation.<p>* Bug&#x2F;Bad Feature - John references the button correctly, but fails to handle certain state resets properly when the form is cancelled.<p>-----<p>The prior is technical debt because it works correctly, but doesn&#x27;t follow a good pattern or does something unexpected (refactoring that button will be much, much harder). The latter is likely just bad code.<p>The case where the latter is not bad code is if the company has made an intentional decision to not handle cancel edge cases. Even here, I would argue that is product debt - not technical debt.<p>----<p>Every software product in the world has debt. Just like every software product in the world has bugs. You need to account for your debt as you grow. Otherwise it will eat you.