The thing I like about “technical debt” that I haven’t seen any other terms capture is that, like financial debt, it is a
tool. If you’re building a new feature, there’s often a choice between doing it “right” and doing it “quick”. And it’s not a choice with a correct answer. If it’s important to get the feature to market ASAP, it might make sense to build it quickly even though you’ll have to refactor it in the future!
Calling it “bad code” definitely misses the mark. IMO, it’s code that constrains you from doing things you want to do. Tech debt is almost always code that is tightly coupled to other code, which is why getting rid of it or working in codebases with a lot of it can be difficult.
The key is that (again, like financial debt) you need a plan to pay technical debt down. If there’s too much, you start drowning in it. And not all of it is a choice — sometimes things unexpectedly change and current code becomes a liability. But framing technical debt in architectural decisions as a tool and a choice has helped me understand better how to accomplish business objectives as an engineer.
Calling it “bad code” definitely misses the mark. IMO, it’s code that constrains you from doing things you want to do. Tech debt is almost always code that is tightly coupled to other code, which is why getting rid of it or working in codebases with a lot of it can be difficult.
The key is that (again, like financial debt) you need a plan to pay technical debt down. If there’s too much, you start drowning in it. And not all of it is a choice — sometimes things unexpectedly change and current code becomes a liability. But framing technical debt in architectural decisions as a tool and a choice has helped me understand better how to accomplish business objectives as an engineer.