I have for the most part stopped using the term technical debt, especially when talking to non engineers. There are many reasons why I believe it is an excepti

I have for the most part stopped using the term technical debt, especially when talking to non engineers. There are many reasons why I believe it is an exceptionally poor term, not the least of which being that, unlike monetary debt, technical debt is not quantifiable. Imagine approaching your CFO and convincing him to take out financing to fund an upcoming project, and bring completely unable to tell him the principal amount, the interest or the terms of repayment. I’ve certainly never seen any organization buy into the metaphor deeply enough that they were capable of reasoning about it with anything close to such financial permission. The term I prefer and use quite frequently these days is “technical health.” As in, choosing to continue to the next project without refactoring the new features that we rushed to deliver will negative impact technical health. Technically unhealthy code or services are slow, complex, unreliable, not performant and cumbersome. Technically healthy services allow us to be nimble, to make changes with ease and speed. They are easy to work with and easy to reason about, particularly when things go wrong.