8 ms·

The article links tech debt to financial debt early on, and this is exactly what the analogy is - it is best to be as literal as possible about it. What is goo

The article links tech debt to financial debt early on, and this is exactly what the analogy is - it is best to be as literal as possible about it. What is good debt? It's taking money from someone, promising to pay them back more money in the future, and using the original money to make even more money than that, so both you and the lender profit. Good tech debt is just the same. It's taking shortcuts now to save time and get something shipped, knowing that it will cost you more time than you're saving now to fix it later. But by shipping now, you ensure there is a later, with a product that's out there and being used, a bigger team and therefore adequate time and then some to fix the debt and keep improving the product. Everyone wins. That's the theory anyway. I think mostly where it goes awry in the wild is people forgetting the paying it off part. Part of this deal is you have to pay back your lender - they have to win too. It's just easily forgotten because you're the lender, so the incentives get a bit conflicted, and you'll keep giving yourself more time. But if the lender ultimitely doesn't get paid back and loses, you lose, and it's a bad debt.

matchagaucho 7y ago
Ward Cunningham, who coined the term "Technical Debt", would often use the analogy "If you borrowed $500K for a house that is now worth $1M..."
- chris_wot 7y ago
  Michael Feathers said that he doesn’t use the term when working for banks as they don’t see it as a negative term...
tempestn 7y ago
> I think mostly where it goes awry in the wild is people forgetting the paying it off part. Which also fits the financial debt analogy perfectly.
- eikenberry 7y ago
  What would bankruptcy be analogous to... the business going under? Having to rewrite the application due to unmaintainable code?
  - mcondit 7y ago
    oh it definitely is a rewrite
  - fireflies_ 7y ago
    Probably a rewrite – HNers always seem to have stories about being brought in to work on companies with incomprehensible rats nests of code that are impossible to extend any further. I bet that's pretty common, more common than technical debt actually forcing the company under. Still if you really want to take the analogy further declaring technical bankruptcy could cause business bankruptcy (see Joel Spolsky). You probably want to refinance your debt and get onto a repayment plan (an incremental rewrite) instead.
  - devonkim 7y ago
    Bankruptcy is more correctly letting you get away from obligations to creditors with lesser terms to the creditors than originally agreed because you can no longer pay it back. I think there’s nothing very close to this for technical debt because even in a rewrite there’s new debt involved. A rewrite is a lot closer to refinancing where the value of the asset is re-evaluated and new terms of debt repayment are structured that stakeholders agree to. Most people seem familiar with chapter 7 bankruptcies but there’s 11 and 13 too. Furthermore, bankruptcy is about handling an original amount lended - rewrites oftentimes are done with lessons learned from the original version (rewriting from Python to Go isn’t bankruptcy). Technical debt bankruptcy is probably closer to shutting down a service / product with no replacement - the effort has already been spent and you’re walking away from costs without caring for the creditors (customers and engineers alike). The question of whether technical debt can be zeroed in a technical bankruptcy is who the creditors of technical debt really are - is it the business as a whole or the engineers that maintain this stuff? To me, the state of technical debt bankruptcy is a business in a zombie state unable to grow to service the debts because of the technical debts keeping them uncompetitive rather than something more fundamentally wrong with the business like product market fit or bad reputation.
wellpast 7y ago
> The article links tech debt to financial debt early on, and this is exactly what the analogy is - it is best to be as literal as possible about it. Financial debt has a clear quantitative measure. Tech Debt is an incredibly fuzzy concept, even as a qualitative measure, to the point of being useless for anything other than covering one's ass. We can do better as engineers than resting on such fuzzy thinking.
- deleted 7y ago
  [deleted]
- skybrian 7y ago
  Yes, it's a nebulous metaphor. Taking it too seriously is a mistake. But I'm not sure we can do much better? What would you suggest? I like the Go concept of aji [1] but that's too obscure, nobody will get it. Maybe something like "unfinished business" would work? A nebulous term for a nebulous concept. [1] https://senseis.xmp.net/?Aji https://senseis.xmp.net/?Aji
  - wellpast 7y ago
    What I suggest is you try to run a project and deliberately avoid reaching for the concept of "Technical Debt". You will find yourself squirming a little. It will be uncomfortable at first. But if you hold to your guns, you will find that you're forced to speak in much more clear terms about your process and decision-making. And you will certainly find yourself saying humble things like "I have a sense that this isn't the best solution, but it's all I got right now." But over time you'll find yourself improving. You'll find yourself saying "I have a sense that this isn't the best solution -- oh, you know what I just realized, this design choice is going make this other requirement over here nearly impossible to implement." And with this kind of clarity you'll be in a much much better position to navigate the territory ahead and make clear, conscious decisions based on what you know and don't know. "Tech Debt" is simply a way to dodge -- e.g., dodge the discomfort of not knowing stuff, of holding yourself to clear thinking, of admitting the need to improve...
- aeorgnoieang 7y ago
TheLastPass 7y ago
One important difference between tech debt and financial debt, is that if the project you accrued a bunch of tech debt in gets killed for unrelated reasons before it's completed, your debt is forgiven. You never pay it off, and you never have to. When you're validating an idea, don't worry about making everything perfect. Worry about validating the idea. Once you're more confident that you're actually gonna do it long-term, then it starts being more beneficial to pay off the tech debt.
- poslathian 7y ago
  Commercial lending has this component as well. Any real estate operator working at scale will have some experience with giving this or that project back to the bank.
- ghostbrainalpha 7y ago
  Isn't that more of a similarity than a difference? When financial debt gets overwhelming you can declare bankruptcy and abandon the project as well.
  - TheLastPass 7y ago
    No. Bankruptcy doesn't just eliminate the debt and let you move on consequence-free - it's a legal process in which a plan is put in place for everyone to get their fair share of what's left, or to recover from the debt without the debt itself destroying future productivity. It can also be very detrimental to your credit opportunities. If you abandon a project, you're just never going to repay the debt or suffer from any consequences of it.
- caymanjim 7y ago
  > One important difference between tech debt and financial debt, is that if the project you accrued a bunch of tech debt in gets killed for unrelated reasons before it's completed, your debt is forgiven. You never pay it off, and you never have to. This happens with financial debt as well. It's the risk that drives interest rates. Financial debt is abandoned (or restructured) when people or companies file for bankruptcy, when homes are foreclosed on, etc. Sure, it might ding your personal credit history in some cases, but financial debt is constantly abandoned at little or no cost to the borrower.
tziki 7y ago
A big part of technical debt is that often... you just don't have to pay. This is what makes the comparison to financial debt a very poor one. Whenever I'm moving from one framework to another I find loads of todos I can now delete. Or even if I have a well designed class, if I can find a nice third party library that does the exact same thing, I can now get rid of all that useless code and any debt around it. Honestly I think calling it technical 'debt' makes programmers unreasonably averse to it, but unfortunately I haven't been able to come up with a better term.
- mobjack 7y ago
  Tech debt is mainly a problem with code that needs frequent updates as it makes changes harder. If you have messy code that doesn't need updating, then it doesn't cost a thing to leave it in a bad state. The act of refactoring in these cases is a waste of effort and often does more harm than good by introducing bugs. I take the YAGNI when it comes to refactoring. Just pay back the stuff if the code actually slows you down in the future instead of doing it in advance. There is a lot of tech debt you can get away with for free without ever having to pay back.
- saagarjha 7y ago
  So you're declaring tech bankruptcy.
tyingq 7y ago
A little trickier maybe in that some tech debt is in the eye of the beholder. Some may consider an Angular UI tech debt, others might consider it an asset versus, say, React + whatever other parts it needs.

matchagaucho 7y ago

Ward Cunningham, who coined the term "Technical Debt", would often use the analogy "If you borrowed $500K for a house that is now worth $1M..."

chris_wot 7y ago
Michael Feathers said that he doesn’t use the term when working for banks as they don’t see it as a negative term...

tempestn 7y ago

> I think mostly where it goes awry in the wild is people forgetting the paying it off part. Which also fits the financial debt analogy perfectly.

eikenberry 7y ago
What would bankruptcy be analogous to... the business going under? Having to rewrite the application due to unmaintainable code?
- mcondit 7y ago
  oh it definitely is a rewrite
- fireflies_ 7y ago
  Probably a rewrite – HNers always seem to have stories about being brought in to work on companies with incomprehensible rats nests of code that are impossible to extend any further. I bet that's pretty common, more common than technical debt actually forcing the company under. Still if you really want to take the analogy further declaring technical bankruptcy could cause business bankruptcy (see Joel Spolsky). You probably want to refinance your debt and get onto a repayment plan (an incremental rewrite) instead.
- devonkim 7y ago
  Bankruptcy is more correctly letting you get away from obligations to creditors with lesser terms to the creditors than originally agreed because you can no longer pay it back. I think there’s nothing very close to this for technical debt because even in a rewrite there’s new debt involved. A rewrite is a lot closer to refinancing where the value of the asset is re-evaluated and new terms of debt repayment are structured that stakeholders agree to. Most people seem familiar with chapter 7 bankruptcies but there’s 11 and 13 too. Furthermore, bankruptcy is about handling an original amount lended - rewrites oftentimes are done with lessons learned from the original version (rewriting from Python to Go isn’t bankruptcy). Technical debt bankruptcy is probably closer to shutting down a service / product with no replacement - the effort has already been spent and you’re walking away from costs without caring for the creditors (customers and engineers alike). The question of whether technical debt can be zeroed in a technical bankruptcy is who the creditors of technical debt really are - is it the business as a whole or the engineers that maintain this stuff? To me, the state of technical debt bankruptcy is a business in a zombie state unable to grow to service the debts because of the technical debts keeping them uncompetitive rather than something more fundamentally wrong with the business like product market fit or bad reputation.

wellpast 7y ago

> The article links tech debt to financial debt early on, and this is exactly what the analogy is - it is best to be as literal as possible about it. Financial debt has a clear quantitative measure. Tech Debt is an incredibly fuzzy concept, even as a qualitative measure, to the point of being useless for anything other than covering one's ass. We can do better as engineers than resting on such fuzzy thinking.

deleted 7y ago
[deleted]
skybrian 7y ago
Yes, it's a nebulous metaphor. Taking it too seriously is a mistake. But I'm not sure we can do much better? What would you suggest? I like the Go concept of aji [1] but that's too obscure, nobody will get it. Maybe something like "unfinished business" would work? A nebulous term for a nebulous concept. [1] https://senseis.xmp.net/?Aji https://senseis.xmp.net/?Aji
- wellpast 7y ago
  What I suggest is you try to run a project and deliberately avoid reaching for the concept of "Technical Debt". You will find yourself squirming a little. It will be uncomfortable at first. But if you hold to your guns, you will find that you're forced to speak in much more clear terms about your process and decision-making. And you will certainly find yourself saying humble things like "I have a sense that this isn't the best solution, but it's all I got right now." But over time you'll find yourself improving. You'll find yourself saying "I have a sense that this isn't the best solution -- oh, you know what I just realized, this design choice is going make this other requirement over here nearly impossible to implement." And with this kind of clarity you'll be in a much much better position to navigate the territory ahead and make clear, conscious decisions based on what you know and don't know. "Tech Debt" is simply a way to dodge -- e.g., dodge the discomfort of not knowing stuff, of holding yourself to clear thinking, of admitting the need to improve...
aeorgnoieang 7y ago

TheLastPass 7y ago

One important difference between tech debt and financial debt, is that if the project you accrued a bunch of tech debt in gets killed for unrelated reasons before it's completed, your debt is forgiven. You never pay it off, and you never have to. When you're validating an idea, don't worry about making everything perfect. Worry about validating the idea. Once you're more confident that you're actually gonna do it long-term, then it starts being more beneficial to pay off the tech debt.

poslathian 7y ago
Commercial lending has this component as well. Any real estate operator working at scale will have some experience with giving this or that project back to the bank.
ghostbrainalpha 7y ago
Isn't that more of a similarity than a difference? When financial debt gets overwhelming you can declare bankruptcy and abandon the project as well.
- TheLastPass 7y ago
  No. Bankruptcy doesn't just eliminate the debt and let you move on consequence-free - it's a legal process in which a plan is put in place for everyone to get their fair share of what's left, or to recover from the debt without the debt itself destroying future productivity. It can also be very detrimental to your credit opportunities. If you abandon a project, you're just never going to repay the debt or suffer from any consequences of it.
caymanjim 7y ago
> One important difference between tech debt and financial debt, is that if the project you accrued a bunch of tech debt in gets killed for unrelated reasons before it's completed, your debt is forgiven. You never pay it off, and you never have to. This happens with financial debt as well. It's the risk that drives interest rates. Financial debt is abandoned (or restructured) when people or companies file for bankruptcy, when homes are foreclosed on, etc. Sure, it might ding your personal credit history in some cases, but financial debt is constantly abandoned at little or no cost to the borrower.

tziki 7y ago

A big part of technical debt is that often... you just don't have to pay. This is what makes the comparison to financial debt a very poor one. Whenever I'm moving from one framework to another I find loads of todos I can now delete. Or even if I have a well designed class, if I can find a nice third party library that does the exact same thing, I can now get rid of all that useless code and any debt around it. Honestly I think calling it technical 'debt' makes programmers unreasonably averse to it, but unfortunately I haven't been able to come up with a better term.

mobjack 7y ago
Tech debt is mainly a problem with code that needs frequent updates as it makes changes harder. If you have messy code that doesn't need updating, then it doesn't cost a thing to leave it in a bad state. The act of refactoring in these cases is a waste of effort and often does more harm than good by introducing bugs. I take the YAGNI when it comes to refactoring. Just pay back the stuff if the code actually slows you down in the future instead of doing it in advance. There is a lot of tech debt you can get away with for free without ever having to pay back.
saagarjha 7y ago
So you're declaring tech bankruptcy.

tyingq 7y ago

A little trickier maybe in that some tech debt is in the eye of the beholder. Some may consider an Angular UI tech debt, others might consider it an asset versus, say, React + whatever other parts it needs.