As en engineer I understand and agree with what the author is saying: technical debt is a loaded term and it feels wrong to throw it around liberally to cover things that should have discrete and distinct meanings.  However: the term &quot;technical debt&quot; is not for engineer-to-engineer communication: it is for communicating to management and other non-technical actors - and in that role the term perfectly suits its purpose.<p>To understand why, let&#x27;s consider a normal interaction with a corporate legal team.  The content team submits some copy to the legal team for approval and the legal team needs to communicate to the content team that they can&#x27;t make the claim they are trying to make about the product.  Now, it&#x27;s more true in the technical sense for legal to say things like &quot;Section 3 paragraph 7 of the Fair Sales Act states that Consumer Entities as defined in Section 1 Paragraph 3 may not represent their products in such a way as to potentially mislead a Purchaser as defined in Section 2 paragaph 9. Furthermore this issue has been thoroughly litigated at both the federal appellate and Supreme Court levels which have reinforced those interpretations unfavorable to the aforementioned Consumer Entity.&quot; But that wouldn&#x27;t be great for either department.  It&#x27;s more useful for Legal to just say &quot;You can&#x27;t claim that - we&#x27;ll get sued.&quot; In a similar way, it&#x27;s more useful as a software engineer to just say &quot;that decision will add to our technical debt&quot; than to try and discuss the minutiae of how a certain bad architecture decision will make the system &quot;resistant to change&quot;.  As a fellow engineer, I&#x27;d rather have the latter conversation with you and the one about &quot;technical debt&quot; with my business manager.