5 ms·

I worked with Ward Cunningham for about a year, and he said once that he regretted coining the phrase “technical debt.” He said it allowed people to think of th

I worked with Ward Cunningham for about a year, and he said once that he regretted coining the phrase “technical debt.” He said it allowed people to think of the debt in a bottomless way: once you’ve accumulated some, why not a little more? After all, the first little bit didn’t hurt us, did it? The end result of this thinking is the feature factory, where a company only ever builds new features, usually to attract new customers. Necessary refactors are called “tech debt” and left to pile up. Yes, this is just another view of bad management, but still, Ward thought that the metaphor afforded it too easily. He said he wished instead that he’d coined “opportunity,” as in, producing or consuming it. Good practices produce opportunity. Opportunity can then be consumed in order to meet certain short-term goals. So it flips the baseline. Rather than having a baseline of quality then dipping below it into tech debt, you’d produce opportunity to put you above the baseline. Once you have this opportunity, you consume it to get back to baseline but not below. I’m not convinced that the concept phrased thus would have the same traction. Still, I love this way of looking at it, like I love much of Ward’s POV on the world.

NoMoreNicksLeft 3y ago
> I worked with Ward Cunningham for about a year, and he said once that he regretted coining the phrase “technical debt.” He said it allowed people to think of the debt in a bottomless way: once you’ve accumulated some, why not a little more? After all, the first little bit didn’t hurt us, did it? I suspect that at the foundational level of this metaphor, the true problem is that some/most people treat financial debt the same, until they're evicted and the car has been repossessed and they've got a warrant out for their failure to show in court. I want to be wrong about that. Someone tell me I'm wrong.
brianpan 3y ago
> He said it allowed people to think of the debt in a bottomless way: once you’ve accumulated some, why not a little more? After all, the first little bit didn’t hurt us, did it? Isn't this exactly how people mismanage financial debt? If anything it shows the analogy is a good one.
- zizee 3y ago
  At least with financial debt, the lender is doing their own due diligence, and is explicit with their book keeping, and repayment terms.
divbzero 3y ago
Sticking with the balance sheet analogy, the phrase would be “technical asset”.
- CSMastermind 3y ago
  I've always used the phrase "technical wealth" to explain the opposite of technical debt. But I agree your term works a little better since you can have both assets and liabilities and ideally you want to be wealthy not indebted.
- kragen 3y ago
  unfortunately, current practice uses the word 'asset' to mean 'file' (or, more specifically, 'file that we are going to put on a web server') i think this is the wrong side of the balance sheet, so in dercuano i put my fonts and css in a 'liabilities' directory instead
neilk 3y ago
That's fantastic. I have been lucky enough to cross paths with Ward Cunningham a couple of times and I am always struck by his insight. Kellan Elliot-McCrae has a similar take on technical debt. In his view there is very little technical debt as traditionally defined - an intentional decision to take a shortcut now that we remediate later. Instead, "tech debt" is typically a label applied to code that makes developers sad because it resists change. Kellan breaks it down further in this article. https://kellanem.com/notes/towards-an-understanding-of-technical-debt https://kellanem.com/notes/towards-an-understanding-of-techn...
Procrastes 3y ago
I've been trying out "Technical Wealth" for that purpose. I think it was coined by Andrea Goulet.
justinjlynn 3y ago
Technical uncovered short position. Nothing wrong with taking a short position on a technical aspect of the project/product and taking the premium right now - so long as you hedge your bets. Otherwise you might have the contract assigned and go bankrupt, or fail to deliver the asset promised and lose everything. There's a reason purposefully taking uncovered short positions is illegal in most developed markets...
jongjong 3y ago
I agree with the author of the article that the metaphor is actually very fitting. That said, I think Ward Cunningham's view is also correct in the context of how debt is viewed today. That said, historically, debt has been regarded as something which was bad for the borrower and only good for the lender. The distortion likely came about because of reserve bank near-0% interest rate policies enabled by unlimited 'money printing'. Once reserve banks started offering near-0% interest rate loans, private banks found that they could still make big profits by making loans to people on very low margins like 2% to 5% interest rates (since they could themselves borrow upstream at 0%)... But these rates are impossibly low if you think about it. Would any private citizen in their right mind loan their own hard-earned money to other people for 5% interest per year? Let alone while knowing that inflation is almost 5%? Even ignoring inflation which entirely cancels out all the profit, nominally, it barely even covers the risk of the borrower stealing the money and leaving the country... Today, private lending doesn't make sense from the lender's perspective, even when you ignore inflation. Direct lending of one's own money today only makes sense for very risky short term loans with unethically high interest rates (loan sharks). Anyway, to get back to the point; low interest rates brought on by reserve bank manipulation are unnatural; they made the deal unnaturally good for the borrower (at the expense of the average citizen). Historically, debt was in fact correctly perceived as dangerous for the borrower.
- 3np 3y ago
  The point where the analogy breaks in theory and practice is this combined with the mythical man-month: > That feels unexpected. If we're doing so well, why would we want to take on more tech debt? But think of it this way: if your product (thus company) are really growing that fast, you will have more people to pay down the tech debt next year than you do now.
xnx 3y ago
I'll take a feature factory over a refactor factory any day.
lumost 3y ago
I've also found that the term can be used to describe anything. Some folks would think of anything that isn't "shiny new framework" as tech debt. Some folks think of unsupported features as tech debt. Some folks think that the 2 million line monolithic code base producing billions of profit per year is tech debt. After seeing a few too many tech debt reduction programs yield even more tech debt than they started with... I simply don't buy retrospective arguments any more. Decide what is acceptable/unacceptable at design time, don't strangle yourself on it after the fact.
- tempodox 3y ago
  Any term can be abused, but that doesn't make it meaningless.
- wpietri 3y ago
  Sorry, but I don't understand this. Tech debt it any mess that makes it harder to improve the product. You have to pay cost without getting any new value; the benefit for the cost was received previously. People may misuse the term, but it has a pretty clear meaning. I also don't understand what "design time" could mean these days. 30 years ago, when release cycles were 18-36 months, it was a real thing. But now? With modern release cadences, we are always designing the system. Which is great, because the quality of design is limited by our knowledge, and our knowledge increases over time. Setting our standards early on in a project, when we're most ignorant, guarantees we'll be setting the bar wrong.
  - cratermoon 3y ago
    > Tech debt it any mess that makes it harder to improve the product. Technical debt is absolutely NOT just "any mess that makes it harder to improve the product", not in its original formulation, and that's what GP comment is saying. Ward says directly, "A lot of bloggers at least have explained the debt metaphor and confused it, I think, with the idea that you could write code poorly with the intention of doing a good job later and thinking that that was the primary source of debt."[0] Technical debt here, and in the linked article, refers to specific, intentional choices about features and behavior. I've taking to call thing formulation "Classic" or "Traditional" technical debt, to differentiate it from the more widely used definition that includes "any mess". In other words, a mess is not a Technical Debt, or as Andy Cleff says[1], "you don’t have Technical Debt – you have a mess, you have cruft: An unpleasant substance, the result of shoddy construction, redundant, old or improperly written code." 0 http://wiki.c2.com/?WardExplainsDebtMetaphor http://wiki.c2.com/?WardExplainsDebtMetaphor 1 https://www.andycleff.com/2022/03/technical-debt-what-it-is-where-it-comes-from-how-to-pay-it-down/ https://www.andycleff.com/2022/03/technical-debt-what-it-is-...
marcosdumay 3y ago
> The end result of this thinking is the feature factory I'm not sure how relevant this is, but a feature factory is the result of people contracting software development, and measuring it by features; nothing more. Any other characteristic is a consequence, not a cause.
- seadan83 3y ago
  I don't believe contracting of any type us needed for a feature factory. It is more when product and project managers hijack the roadmap (or even create a roadmap at all) and then March along adding things for the sake of delivering story points, and the "it was _my_ team and _my_ vision that built this", rather than building on others work. I think a good D&D analogy is your group needs a fighter. Instead of leveling up your decent level 6 fighter to level 7,8 and 9, instead you start multi classing, picking up some droid abilities cause, hey, surely it's cool Regardless, here is something that describes feature factory in more detail: https://www.productplan.com/glossary/feature-factory/ https://www.productplan.com/glossary/feature-factory/ A huge part of feature factory, worth mentioning, is any lack of checking (let alone measuring), did we build the right thing?
  - marcosdumay 3y ago
    I believe you had the luck of never taking part on the extremely demoralizing exercise that is somebody deciding on the next steps for the software, writing it down and passing alone to somebody that will manage the development of that written thing; at the same side, some developers come, get the written down, non-negotiable decisions, and make their best on creating that stuff, fully aware that their continuing employment depends on satisfying the letter of those acceptance conditions, and the salary amount must be justified every time by delivering that in a market-competitive time. In a feature factory, the developers do not get to know if there is a roadmap or not. It's not of their concern, and the competitive nature of the bids ensures that they won't have time to think about it anyway. I don't think that this arrangement is even possible for hired developers.
- vinibrito 3y ago
  You just expanded my mind with that today. Well, so we can raise above the status quo, how else would development be contracted?
commandlinefan 3y ago
Another problem with the analogy is that you can meaningfully make a $0.01 payment on your debt. You can pick any arbitrary percentage of your debt and pay it off right now, if you have the money to do so. Programming tasks are not only more (unpredictably) quantized than that, they're usually Sisyphean: if you do a little but don't finish, you've wasted the time you spent because the boulder rolls back down as soon as you stop pushing.
- Libcat99 3y ago
  In fact, doing a little and not finishing might make things worse! You may end up with things like compatability modes, extra options, and the like. But don't worry, you can clean it up later.
- bluGill 3y ago
  You can never make a $0.01 payment on any debt. You can try, but interest means your debt will grow faster than your payments! In the case of technical debt, interest is the recurring costs of working in the less than ideal code.
- xedrac 3y ago
  That is a good point. Tech debt is often, but not always, harder to pay back in small amounts.
JJMcJ 3y ago
Enough technical debt and your project is on "technical payday loans". I've worked on such projects and it's no fun.
- deleted 3y ago
  [deleted]
dasil003 3y ago
Totally agree with that, but I don't think regret is warranted. The power of "technical debt" is that it was actually catchy enough to get a foothold with the MBAs and pointy hairs. That alone is a victory. Any sufficiently good idea with a catchy meme is subject to cargo culting and abuse. We need look no further than The Agile Manifesto to see how thoroughly any well-summarized wisdom, drawn from a well of deep expertise, lovingly word-smithed with the utmost clarity, can be abused and twisted into a hideous monstrosity that is, in fact, the complete opposite of the original intent.
m463 3y ago
Don't forget people use ambiguity as a tool all the time. Politicians use words like "justice" or "freedom" to create common ground with little controversy even when they define the term in a way diametrically opposed to their constituents. I think it can be the same with "tech debt". I have a friend who figures when he sells his house it will be a tear-down, so he has all kinds of "house tech debt" that he just manages to live with until he literally moves on. it basically means "I don't care about fixing that" or "I'm not going to fix that ever".

NoMoreNicksLeft 3y ago

> I worked with Ward Cunningham for about a year, and he said once that he regretted coining the phrase “technical debt.” He said it allowed people to think of the debt in a bottomless way: once you’ve accumulated some, why not a little more? After all, the first little bit didn’t hurt us, did it? I suspect that at the foundational level of this metaphor, the true problem is that some/most people treat financial debt the same, until they're evicted and the car has been repossessed and they've got a warrant out for their failure to show in court. I want to be wrong about that. Someone tell me I'm wrong.

brianpan 3y ago

> He said it allowed people to think of the debt in a bottomless way: once you’ve accumulated some, why not a little more? After all, the first little bit didn’t hurt us, did it? Isn't this exactly how people mismanage financial debt? If anything it shows the analogy is a good one.

zizee 3y ago
At least with financial debt, the lender is doing their own due diligence, and is explicit with their book keeping, and repayment terms.

divbzero 3y ago

Sticking with the balance sheet analogy, the phrase would be “technical asset”.

CSMastermind 3y ago
I've always used the phrase "technical wealth" to explain the opposite of technical debt. But I agree your term works a little better since you can have both assets and liabilities and ideally you want to be wealthy not indebted.
kragen 3y ago
unfortunately, current practice uses the word 'asset' to mean 'file' (or, more specifically, 'file that we are going to put on a web server') i think this is the wrong side of the balance sheet, so in dercuano i put my fonts and css in a 'liabilities' directory instead

neilk 3y ago

That's fantastic. I have been lucky enough to cross paths with Ward Cunningham a couple of times and I am always struck by his insight. Kellan Elliot-McCrae has a similar take on technical debt. In his view there is very little technical debt as traditionally defined - an intentional decision to take a shortcut now that we remediate later. Instead, "tech debt" is typically a label applied to code that makes developers sad because it resists change. Kellan breaks it down further in this article. https://kellanem.com/notes/towards-an-understanding-of-technical-debt https://kellanem.com/notes/towards-an-understanding-of-techn...

Procrastes 3y ago

I've been trying out "Technical Wealth" for that purpose. I think it was coined by Andrea Goulet.

justinjlynn 3y ago

Technical uncovered short position. Nothing wrong with taking a short position on a technical aspect of the project/product and taking the premium right now - so long as you hedge your bets. Otherwise you might have the contract assigned and go bankrupt, or fail to deliver the asset promised and lose everything. There's a reason purposefully taking uncovered short positions is illegal in most developed markets...

jongjong 3y ago

I agree with the author of the article that the metaphor is actually very fitting. That said, I think Ward Cunningham's view is also correct in the context of how debt is viewed today. That said, historically, debt has been regarded as something which was bad for the borrower and only good for the lender. The distortion likely came about because of reserve bank near-0% interest rate policies enabled by unlimited 'money printing'. Once reserve banks started offering near-0% interest rate loans, private banks found that they could still make big profits by making loans to people on very low margins like 2% to 5% interest rates (since they could themselves borrow upstream at 0%)... But these rates are impossibly low if you think about it. Would any private citizen in their right mind loan their own hard-earned money to other people for 5% interest per year? Let alone while knowing that inflation is almost 5%? Even ignoring inflation which entirely cancels out all the profit, nominally, it barely even covers the risk of the borrower stealing the money and leaving the country... Today, private lending doesn't make sense from the lender's perspective, even when you ignore inflation. Direct lending of one's own money today only makes sense for very risky short term loans with unethically high interest rates (loan sharks). Anyway, to get back to the point; low interest rates brought on by reserve bank manipulation are unnatural; they made the deal unnaturally good for the borrower (at the expense of the average citizen). Historically, debt was in fact correctly perceived as dangerous for the borrower.

3np 3y ago
The point where the analogy breaks in theory and practice is this combined with the mythical man-month: > That feels unexpected. If we're doing so well, why would we want to take on more tech debt? But think of it this way: if your product (thus company) are really growing that fast, you will have more people to pay down the tech debt next year than you do now.

xnx 3y ago

I'll take a feature factory over a refactor factory any day.

lumost 3y ago

I've also found that the term can be used to describe anything. Some folks would think of anything that isn't "shiny new framework" as tech debt. Some folks think of unsupported features as tech debt. Some folks think that the 2 million line monolithic code base producing billions of profit per year is tech debt. After seeing a few too many tech debt reduction programs yield even more tech debt than they started with... I simply don't buy retrospective arguments any more. Decide what is acceptable/unacceptable at design time, don't strangle yourself on it after the fact.

tempodox 3y ago
Any term can be abused, but that doesn't make it meaningless.
wpietri 3y ago
Sorry, but I don't understand this. Tech debt it any mess that makes it harder to improve the product. You have to pay cost without getting any new value; the benefit for the cost was received previously. People may misuse the term, but it has a pretty clear meaning. I also don't understand what "design time" could mean these days. 30 years ago, when release cycles were 18-36 months, it was a real thing. But now? With modern release cadences, we are always designing the system. Which is great, because the quality of design is limited by our knowledge, and our knowledge increases over time. Setting our standards early on in a project, when we're most ignorant, guarantees we'll be setting the bar wrong.
- cratermoon 3y ago
  > Tech debt it any mess that makes it harder to improve the product. Technical debt is absolutely NOT just "any mess that makes it harder to improve the product", not in its original formulation, and that's what GP comment is saying. Ward says directly, "A lot of bloggers at least have explained the debt metaphor and confused it, I think, with the idea that you could write code poorly with the intention of doing a good job later and thinking that that was the primary source of debt."[0] Technical debt here, and in the linked article, refers to specific, intentional choices about features and behavior. I've taking to call thing formulation "Classic" or "Traditional" technical debt, to differentiate it from the more widely used definition that includes "any mess". In other words, a mess is not a Technical Debt, or as Andy Cleff says[1], "you don’t have Technical Debt – you have a mess, you have cruft: An unpleasant substance, the result of shoddy construction, redundant, old or improperly written code." 0 http://wiki.c2.com/?WardExplainsDebtMetaphor http://wiki.c2.com/?WardExplainsDebtMetaphor 1 https://www.andycleff.com/2022/03/technical-debt-what-it-is-where-it-comes-from-how-to-pay-it-down/ https://www.andycleff.com/2022/03/technical-debt-what-it-is-...

marcosdumay 3y ago

> The end result of this thinking is the feature factory I'm not sure how relevant this is, but a feature factory is the result of people contracting software development, and measuring it by features; nothing more. Any other characteristic is a consequence, not a cause.

seadan83 3y ago
I don't believe contracting of any type us needed for a feature factory. It is more when product and project managers hijack the roadmap (or even create a roadmap at all) and then March along adding things for the sake of delivering story points, and the "it was _my_ team and _my_ vision that built this", rather than building on others work. I think a good D&D analogy is your group needs a fighter. Instead of leveling up your decent level 6 fighter to level 7,8 and 9, instead you start multi classing, picking up some droid abilities cause, hey, surely it's cool Regardless, here is something that describes feature factory in more detail: https://www.productplan.com/glossary/feature-factory/ https://www.productplan.com/glossary/feature-factory/ A huge part of feature factory, worth mentioning, is any lack of checking (let alone measuring), did we build the right thing?
- marcosdumay 3y ago
  I believe you had the luck of never taking part on the extremely demoralizing exercise that is somebody deciding on the next steps for the software, writing it down and passing alone to somebody that will manage the development of that written thing; at the same side, some developers come, get the written down, non-negotiable decisions, and make their best on creating that stuff, fully aware that their continuing employment depends on satisfying the letter of those acceptance conditions, and the salary amount must be justified every time by delivering that in a market-competitive time. In a feature factory, the developers do not get to know if there is a roadmap or not. It's not of their concern, and the competitive nature of the bids ensures that they won't have time to think about it anyway. I don't think that this arrangement is even possible for hired developers.
vinibrito 3y ago
You just expanded my mind with that today. Well, so we can raise above the status quo, how else would development be contracted?

commandlinefan 3y ago

Another problem with the analogy is that you can meaningfully make a $0.01 payment on your debt. You can pick any arbitrary percentage of your debt and pay it off right now, if you have the money to do so. Programming tasks are not only more (unpredictably) quantized than that, they're usually Sisyphean: if you do a little but don't finish, you've wasted the time you spent because the boulder rolls back down as soon as you stop pushing.

Libcat99 3y ago
In fact, doing a little and not finishing might make things worse! You may end up with things like compatability modes, extra options, and the like. But don't worry, you can clean it up later.
bluGill 3y ago
You can never make a $0.01 payment on any debt. You can try, but interest means your debt will grow faster than your payments! In the case of technical debt, interest is the recurring costs of working in the less than ideal code.
xedrac 3y ago
That is a good point. Tech debt is often, but not always, harder to pay back in small amounts.

JJMcJ 3y ago

Enough technical debt and your project is on "technical payday loans". I've worked on such projects and it's no fun.

deleted 3y ago
[deleted]

dasil003 3y ago

Totally agree with that, but I don't think regret is warranted. The power of "technical debt" is that it was actually catchy enough to get a foothold with the MBAs and pointy hairs. That alone is a victory. Any sufficiently good idea with a catchy meme is subject to cargo culting and abuse. We need look no further than The Agile Manifesto to see how thoroughly any well-summarized wisdom, drawn from a well of deep expertise, lovingly word-smithed with the utmost clarity, can be abused and twisted into a hideous monstrosity that is, in fact, the complete opposite of the original intent.

m463 3y ago

Don't forget people use ambiguity as a tool all the time. Politicians use words like "justice" or "freedom" to create common ground with little controversy even when they define the term in a way diametrically opposed to their constituents. I think it can be the same with "tech debt". I have a friend who figures when he sells his house it will be a tear-down, so he has all kinds of "house tech debt" that he just manages to live with until he literally moves on. it basically means "I don't care about fixing that" or "I'm not going to fix that ever".