Technical debt is an awful term, for the reasons @asthasr discussed and more. Real debt has a known interest rate that can’t be changed except by the terms of the contract. With technical “debt”, it’s more like this:
Roll a d6:
1, 2: some other failure or mess makes the "debt" not matter. You "get away" with it.
3: 20% monthly interest rate. Some other poor fucker has to repay it. You get away with it.
4: 50% monthly interest rate. Management gets away with it, implementer doesn't.
5: 200+% monthly interest rate. Project fails. Management may get away with it, if
politically skilled. Implementors find other jobs.
6: Project fails explosively. Roll d12 and consult Extended Damage Table to see
long-term career effects.
“Technical debt” conflates a valid business practice (going into debt) with technical decisions that are usually awful and made only because the interests of management and those of the implementors diverge. Worse yet and perhaps more subtlely, it also justifies the generation of a lot of undesirable follow-on work as “technical debt repayment” when it is perhaps not the right decision to maintain, but to end, the troubled asset. “Technical debt repayment” creates the impression (often false) that if the maintainers just work hard enough, they’ll turn the badly-conceived asset into something with less of a maintenance load (repaying the debt) and that’s often not true. It’s often better to “default” (that is, scrap the failing asset) and start a new project.
I have always hated the term technical debt. The problem is, if I take out significant debt, it’s intentional and will be repaid. I may take out a mortgage and immediately begin paying it off. The length of the repayment term and the interest that will accrue are taken into account and are, in fact, the primary points of negotiation. Technical “debt” has no such parameters; it is not a considered risk.
I think this is because the term technical debt has lot control of its definition, and people toss it about when they really mean carelessness or laziness. I would support calling a balanced consideration of costs and benefits technical debt, but it seems an uphill battle to reclaim the term.
The article has a good one sentence summary at the end which I can’t paste here because fucking medium does something that causes safari to highlight the entire article when I try to grab just a few words.
And finally you should especially worry if your team believes they’re “fixing” or “paying off” technical debt. All code is technical debt. All code is, to varying degrees, an incorrect bet on what the future will look like. You can address issues that are damaging to productivity, operability and morale, but only way to “fix technical debt” is “rm -rf”.
I don’t really agree with that. Obviously the only¹ bug-free code is no code, but you can always reduce the amount of technical debt in any given piece of code. (Indeed, this is why code is never perfect. If you can’t improve it any more, by definition it is optimal.) Assuming otherwise is a fast track to unmanaged problems spiraling out of control.
¹ Down to formal verification and making unwarranted assumptions about correct behavior of hardware.
Thanks - that’s better than what I was going to say. Yes, the idea of talking about it is precisely to convey its seriousness. Neither engineers nor non-engineer managers are immune to trying to pretend it’s not there. Having a way to talk about it as an obligation is important.
In a conversation with a colleague earlier, we settled on the term “friction.” Technical debt might be something like: “I’m going to hard-code this database IP because we have a demo tomorrow. After the demo I am going to put it in a config file and make sure Chef is templating the correct value in.” Friction is more general: anything that slows you down. Leaky abstractions, unclear code, slow builds, …
Technical debt is an awful term, for the reasons @asthasr discussed and more. Real debt has a known interest rate that can’t be changed except by the terms of the contract. With technical “debt”, it’s more like this:
“Technical debt” conflates a valid business practice (going into debt) with technical decisions that are usually awful and made only because the interests of management and those of the implementors diverge. Worse yet and perhaps more subtlely, it also justifies the generation of a lot of undesirable follow-on work as “technical debt repayment” when it is perhaps not the right decision to maintain, but to end, the troubled asset. “Technical debt repayment” creates the impression (often false) that if the maintainers just work hard enough, they’ll turn the badly-conceived asset into something with less of a maintenance load (repaying the debt) and that’s often not true. It’s often better to “default” (that is, scrap the failing asset) and start a new project.
I have always hated the term technical debt. The problem is, if I take out significant debt, it’s intentional and will be repaid. I may take out a mortgage and immediately begin paying it off. The length of the repayment term and the interest that will accrue are taken into account and are, in fact, the primary points of negotiation. Technical “debt” has no such parameters; it is not a considered risk.
I think this is because the term technical debt has lot control of its definition, and people toss it about when they really mean carelessness or laziness. I would support calling a balanced consideration of costs and benefits technical debt, but it seems an uphill battle to reclaim the term.
The article has a good one sentence summary at the end which I can’t paste here because fucking medium does something that causes safari to highlight the entire article when I try to grab just a few words.
I don’t really agree with that. Obviously the only¹ bug-free code is no code, but you can always reduce the amount of technical debt in any given piece of code. (Indeed, this is why code is never perfect. If you can’t improve it any more, by definition it is optimal.) Assuming otherwise is a fast track to unmanaged problems spiraling out of control.
¹ Down to formal verification and making unwarranted assumptions about correct behavior of hardware.
Much of the point of the term was to get people to start considering it. No metaphor is perfect, but I find this one more helpful than not.
Thanks - that’s better than what I was going to say. Yes, the idea of talking about it is precisely to convey its seriousness. Neither engineers nor non-engineer managers are immune to trying to pretend it’s not there. Having a way to talk about it as an obligation is important.
In a conversation with a colleague earlier, we settled on the term “friction.” Technical debt might be something like: “I’m going to hard-code this database IP because we have a demo tomorrow. After the demo I am going to put it in a config file and make sure Chef is templating the correct value in.” Friction is more general: anything that slows you down. Leaky abstractions, unclear code, slow builds, …