It goes something like this… “I’m an important person, if what you were saying was important, I would understand it, I haven’t clue about the intricate details of this problem you’re describing, so it can’t be important.”
ie. Humans discount whatever they don’t understand. Ever heard the phrase, “Don’t overload me with details, just give me the Big Picture”?
So called “Technical Debt” is all thousands of fine fine tiny nitty gritty messy dirty concrete details, as soon as you start describing them…. you have lost.
Eyes glaze over and refocus on nice Big Juicy Money Making Features.
Not all financial debt gets paid off either. (Specific kinds of debt become legally unpersuable after a certain number of years of non-payment – one reason why debt collectors are aggressive about getting even small installments – and bankruptcy or corporate dissolution creates a jubilee on all debts owed by that entity. Plus, historically, lots of places had periodic jubilees on all public & private debts.) So, this isn’t a hole in the metaphor.
That said, I don’t like the metaphor ‘technical debt’ very much, since it’s really the inverse of the situation. Technical debt is not a promise of a technical solution unfulfilled. Instead, “technical hoarding” makes more sense: our problem is that there’s so much borderline-useless crap included that navigating or understanding it is difficult. The piles of crap can be turned toward ad-hoc utility (the way that those famous hoarding brothers created traps to protect them out of piles of rubbish), but ultimately we’d be better served by using the right tool for the job rather than what’s already lying around.
“Instead, “technical hoarding” makes more sense: our problem is that there’s so much borderline-useless crap included that navigating or understanding it is difficult.”
That’s interesting idea. Might fit hoarding if keeping bad code that’s only hurting us when alternatives are available that we can switch to. However, much of this code are productive assets that have bad parts. The bad parts also cost a lot to get rid of. Might even stop the company in its tracks if mission-critical and fails. They usually keep the system as a whole to keep the productive parts despite any bad parts. I don’t think that fits hoarding how we’d normally perceive it.
It’s more like how people keep cars that have various problems because they still get them where they’re going. Something like that.
Right. I don’t deny that the ‘crap’ can be made to be productive. (The Collier bros made deadfall traps out of newspapers & cat litter that were effective enough that it killed one of them!) Instead, my criticism is: when you’re surrounded by stuff, you have a tendency to use what’s around instead of thinking carefully about what’s appropriate – since using the appropriate thing would involve cleaning up what’s already there.
Instead of using a car that has problems because it still drives, this is more along the lines of using a vice grip to undo a bolt because the vice grip is already out while the socket wrenches are at the bottom of the toolbox: it’ll do the job, but about halfway through you realize that it would have been less effort to just get the right-sized socket, and by that point you’ve damaged the head of the bolt so much (shifted the problem statement, in the metaphor) that only the vice grips will work on it anymore.
(I should note that, despite knowing better, I have done that with both code and actual bolts! The more caffeine or other CNS stimulants are in your bloodstream, the closer your projection of difficulty hews to the number of imagined steps, even when you know those steps require wildly different effort. Give me three cups of strong coffee and I will spend sixteen hours making an absolute hash of a four hour problem.)
agreed. toxic assets or perhaps investments that are operating at a loss. because the software actually takes money away from you, it’s not like the money is “in purgatory”, it’s being siphoned away. it’s more like a house or some other physical property that is vacant, and huge, and thus costs a lot of money each month just to keep up without foreclosure.
Let’s tackle the biggest fallacy that results from carrying around this metaphor: That debt must be paid off.
This simply isn’t true. Not every slightly imperfect design decision or code created needs to be revisited and returned to a perfect state or otherwise reworked. Perhaps the bit of code is not read often and runs well. Perhaps it changes rarely.
I see what the author is getting at here. An organization might be tempted to “pay off” technical debt just for its own sake or in order to free up room to “borrow” somewhere else. This is also alluded to at the end when the author says:
Are you “paying off” the debt for the sake of it?
I would argue, however, that if there’s nothing external gained by “paying off” the technical debt then it isn’t really technical debt. We’ve all left a piece of code not-quite-finished and thought “gosh, if I had another month I could make this truly elegant”. But that doesn’t mean we generated technical debt, it just means our output didn’t live up to our own, personal, standards.
The defining characteristic of technical debt, IMHO, is that it imposes external costs on the organization or product. So, yes, the “technical debt” metaphor does break down in this case, but not in the way the author argues.
Some of these traits do overlap, you can ignore code or make design decisions that will cause rework later in exchange for shipping. This is sort of “buying” something using your “debt” but the price isn’t very clear, making this a potentially difficult trade off to evaluate well.
I agree that this bit is true, but it is also often true for corporate financial debt. When a company borrows money it is generally to make some kind of investment (more machines, a new office building, additional inventory). These kinds of investments have the same “clarity” problem as incurring debt in order to ship a product sooner.
Will the new machines work as well as advertised? Will the new office actually improve productivity? Will demand for the product hold up? When we ask ourselves whether a bit of technical debt is “worth it” we really should consider the question from a number of angles, many of which are ultimately qualitative. Financial investments work the same way. Admittedly, it is easier to put at least a veneer of quantitative precision on a financial investment because they have clear units ($ or whatever).
But instead, that there can be benefit from considering and conceptualizing the problem a bit more directly, as a burden, instead of an often rarely measured, poorly defined pool that you can continue to dump things into.
This is basically how financial debt works as well. You only get so much of it before you can’t borrow any more, even in the short term, and in order to be worth the trouble the debt needs to produce some kind of return.
I agree, however, that organizations should more seriously attempt to measure or otherwise evaluate their level of technical debt. This is one place where technical debt is definitely different from financial debt. With financial debt there is an external entity that keeps track for you. Technical debt is basically owed to yourself, so if you don’t keep track, no one will. To me, this is the most important point in this blog post.
Anyway, I don’t disagree with the author that the metaphor isn’t perfect, I just don’t thinks it’s as inaccurate as he or she argues or inaccurate in the ways that he or she argues.
Indeed. Personal debt may be a poor analogy, but if we’re talking about software at companies, then corporate debt is better. Companies always have debt, they pay some off, they borrow more to do so, constantly rolling the debt forward. Until the day comes when they can’t, and then boom, total collapse.
c.f. Bad code isn’t Technical Debt, it’s an unhedged Call Option
Yes, that is a better description…
Except for the perception problem.
It goes something like this… “I’m an important person, if what you were saying was important, I would understand it, I haven’t clue about the intricate details of this problem you’re describing, so it can’t be important.”
ie. Humans discount whatever they don’t understand. Ever heard the phrase, “Don’t overload me with details, just give me the Big Picture”?
So called “Technical Debt” is all thousands of fine fine tiny nitty gritty messy dirty concrete details, as soon as you start describing them…. you have lost.
Eyes glaze over and refocus on nice Big Juicy Money Making Features.
Not all financial debt gets paid off either. (Specific kinds of debt become legally unpersuable after a certain number of years of non-payment – one reason why debt collectors are aggressive about getting even small installments – and bankruptcy or corporate dissolution creates a jubilee on all debts owed by that entity. Plus, historically, lots of places had periodic jubilees on all public & private debts.) So, this isn’t a hole in the metaphor.
That said, I don’t like the metaphor ‘technical debt’ very much, since it’s really the inverse of the situation. Technical debt is not a promise of a technical solution unfulfilled. Instead, “technical hoarding” makes more sense: our problem is that there’s so much borderline-useless crap included that navigating or understanding it is difficult. The piles of crap can be turned toward ad-hoc utility (the way that those famous hoarding brothers created traps to protect them out of piles of rubbish), but ultimately we’d be better served by using the right tool for the job rather than what’s already lying around.
“Instead, “technical hoarding” makes more sense: our problem is that there’s so much borderline-useless crap included that navigating or understanding it is difficult.”
That’s interesting idea. Might fit hoarding if keeping bad code that’s only hurting us when alternatives are available that we can switch to. However, much of this code are productive assets that have bad parts. The bad parts also cost a lot to get rid of. Might even stop the company in its tracks if mission-critical and fails. They usually keep the system as a whole to keep the productive parts despite any bad parts. I don’t think that fits hoarding how we’d normally perceive it.
It’s more like how people keep cars that have various problems because they still get them where they’re going. Something like that.
Right. I don’t deny that the ‘crap’ can be made to be productive. (The Collier bros made deadfall traps out of newspapers & cat litter that were effective enough that it killed one of them!) Instead, my criticism is: when you’re surrounded by stuff, you have a tendency to use what’s around instead of thinking carefully about what’s appropriate – since using the appropriate thing would involve cleaning up what’s already there.
Instead of using a car that has problems because it still drives, this is more along the lines of using a vice grip to undo a bolt because the vice grip is already out while the socket wrenches are at the bottom of the toolbox: it’ll do the job, but about halfway through you realize that it would have been less effort to just get the right-sized socket, and by that point you’ve damaged the head of the bolt so much (shifted the problem statement, in the metaphor) that only the vice grips will work on it anymore.
(I should note that, despite knowing better, I have done that with both code and actual bolts! The more caffeine or other CNS stimulants are in your bloodstream, the closer your projection of difficulty hews to the number of imagined steps, even when you know those steps require wildly different effort. Give me three cups of strong coffee and I will spend sixteen hours making an absolute hash of a four hour problem.)
I think the closer financial construct is a toxic asset.
agreed. toxic assets or perhaps investments that are operating at a loss. because the software actually takes money away from you, it’s not like the money is “in purgatory”, it’s being siphoned away. it’s more like a house or some other physical property that is vacant, and huge, and thus costs a lot of money each month just to keep up without foreclosure.
I see what the author is getting at here. An organization might be tempted to “pay off” technical debt just for its own sake or in order to free up room to “borrow” somewhere else. This is also alluded to at the end when the author says:
I would argue, however, that if there’s nothing external gained by “paying off” the technical debt then it isn’t really technical debt. We’ve all left a piece of code not-quite-finished and thought “gosh, if I had another month I could make this truly elegant”. But that doesn’t mean we generated technical debt, it just means our output didn’t live up to our own, personal, standards.
The defining characteristic of technical debt, IMHO, is that it imposes external costs on the organization or product. So, yes, the “technical debt” metaphor does break down in this case, but not in the way the author argues.
I agree that this bit is true, but it is also often true for corporate financial debt. When a company borrows money it is generally to make some kind of investment (more machines, a new office building, additional inventory). These kinds of investments have the same “clarity” problem as incurring debt in order to ship a product sooner.
Will the new machines work as well as advertised? Will the new office actually improve productivity? Will demand for the product hold up? When we ask ourselves whether a bit of technical debt is “worth it” we really should consider the question from a number of angles, many of which are ultimately qualitative. Financial investments work the same way. Admittedly, it is easier to put at least a veneer of quantitative precision on a financial investment because they have clear units ($ or whatever).
This is basically how financial debt works as well. You only get so much of it before you can’t borrow any more, even in the short term, and in order to be worth the trouble the debt needs to produce some kind of return.
I agree, however, that organizations should more seriously attempt to measure or otherwise evaluate their level of technical debt. This is one place where technical debt is definitely different from financial debt. With financial debt there is an external entity that keeps track for you. Technical debt is basically owed to yourself, so if you don’t keep track, no one will. To me, this is the most important point in this blog post.
Anyway, I don’t disagree with the author that the metaphor isn’t perfect, I just don’t thinks it’s as inaccurate as he or she argues or inaccurate in the ways that he or she argues.
Indeed. Personal debt may be a poor analogy, but if we’re talking about software at companies, then corporate debt is better. Companies always have debt, they pay some off, they borrow more to do so, constantly rolling the debt forward. Until the day comes when they can’t, and then boom, total collapse.