6 ms·

Technical debt isn’t an arbitrary thing; it’s a metaphor to try to explain doing maintenance to non technical folk. The explanation goes like this: If you hav

Technical debt isn’t an arbitrary thing; it’s a metaphor to try to explain doing maintenance to non technical folk. The explanation goes like this: If you have no debt, you can borrow money. If you have a bit of debt, you can borrow money, but you have to make regular repayments of maintenance to service that debt. ...but when you have a lot of debt, lenders are cautious about lending you money. Will you pay it back? Why didn’t you pay back any of your other debts? Can you afford the repayments? The metaphor isn’t perfect, but the point being made is that maintenance is the repayments on technical debt; if ignore it, at some point you are going to end up spending all your developer hours on maintenance, and your throughput for features will grind to a halt. You “repay” the technical debt by fixing stuff that causes problems, not by randomly rewriting it because you can’t be bothered reading the existing source code. It’s not maintenance. That’s a different thing; that’s making changes. Technical debt is more like a metric of how prone to failure /what feature velocity your software is / has. Sure, the metaphor falls over; you can just keep slapping broken features and other crap on top of either other indefinitely if you dont care if your existing features work or not... but, that’s a different issue.

xixixao 6y ago
The article ignores that there are many ways to initially write code, and some are better than others. “Creating technical debt” is about not spending the time to find a good way to initially write the code, leaving it to a later point in time. This should be a cautious decision (and I’ve seen it happen many times, at individual/team/even org level). This is “tech debt”, and it does exist.
- zuppy 6y ago
  > is about not spending the time to find a good way to initially write the code in an ideal world, yeah, that would be the cause, but in reality there are multiple other constraints: - time constraint: you can not spend as much time as you want to make the perfect code (and that is ok, you want to ship and add value to the business so you continue to get your salary - see the extreme case of Duke Nukem Forever) - dependency constraint: sometimes other teams requirement will affect your code quality - cost constraint: again, you don’t want to go bankrupt - competency constraint: there are juniors and there are people who don’t have the knowledge to perfectly cover your requirements etc
  - magicalhippo 6y ago
    There can be many very valid reasons for creating technical dept when writing code. That does not mean technical dept is not a thing or not a real issue in certain codebases. Almost every day I think about the potential technical dept of my code.
  - gwd 6y ago
    Sure, and that's actually 100% normal in business -- it's called the "J-curve". Lots of businesses big and small start their lives, or even start some new project or expansion within an existing business, by borrowing money and then paying it back. The key thing is 1) borrowing money "strategically", and not just willy-nilly and 2) paying it back when you can afford to, rather than continually paying interest on it. It totally makes sense to take on technical debt in order to get your MVP out the door quickly; or to be able to fix an urgent customer issue; or to be able to make a release. And in some cases, it may make sense to keep technical debt around indefinitely. What doesn't make sense is to pile on technical debt for no real benefit, and then not take any time to pay it down. That's like always buying things on your credit card just because you can and only making the minimum payments.
- rumanator 6y ago
  > “Creating technical debt” is about not spending the time to find a good way to initially write the code, leaving it to a later point in time. This is the wrong way to describe and explain technical debt. It fails primarily to sell the wrong idea that technical debt results from incompetence or failure to do a good job. The truth if the matter is that in software development the absolute best solution to a problem is to provide an implementation that meets current requirements and is implemented as fast as possible. Overgeneralizing is bad code. Abstracting implementation details is a code smell. Proposing an implementation that considers additional design requirements and constraints is goldplating a solution, thus the sign of a mix of incompetence and wasted effort. But then what if requirements change? Ah, the delta between the fast and good solution for the initial problem and adapting it with quick fixes to address the new requirements is precisely where technical debt pops up.
  - adrianmonk 6y ago
    You made a good argument that generalizing is an investment that often doesn't pay off. That's a separate issue from technical debt because whether code is generalized is only one aspect of many that determines whether the code is a dream or a nightmare to work with. For example, if all your variable and function names are vague and misleading because you didn't take the time to choose names that make any sense, that saved you time now and will cost you later, but it has nothing to do with generalization.
    - rumanator 6y ago
      > That's a separate issue from technical debt because whether code is generalized is only one aspect of many that determines whether the code is a dream or a nightmare to work with. That's one of the problems attributed to goldplating and over-engineering solutions. One man's future-proof implementation is another man's unnecessary indirection that's a problem to maintain. Thus we end up creating an environment where rigid implementations that are prone to colossal amounts of technical debt are preferred over adaptable solutions that minimize or eliminate technical debt.
  - xixixao 6y ago
user5994461 6y ago
> You “repay” the technical debt by fixing stuff that causes problems Well, that sounds a lot like maintenance.
- sixstringtheory 6y ago
  Maintenance is the repayment, not the debt itself.
- lucideer 6y ago
  As the GP said: > The metaphor isn’t perfect But there's a difference between maintenance that fixes problems expediently and maintenance that fixes problems more permanently. The technical debt metaphor is an attempt to model the cons of doing the former too often (otherwise faster always seems better).
- hajile 6y ago
  Maintenance of good code is very different than going in and fixing a bunch of TODOs so the thing won't break outside the happy path.
galoisgirl 6y ago
Well said. All the smart things I ever read about technical debt basically describe debt and add the word "technical" - because that's what it is. It's not maintenance, it's not refactoring, it's just pure and simple debt.
- user5994461 6y ago
  It's not debt because unlike (financial) debt, there is no way to not take it or to repay it. Technical debt in software is unavoidable. Every variable and function and design decision can invariably be rebranded as technical debt soon enough. The implication of "technical debt" is that there is a perfect state to reach with no debt, but there isn't. It also implies that debt could be avoided but it can't be, it's inherent to development.
  - galoisgirl 6y ago
    I'm writing this as a middle-class person, who has to go into debt if she wants to buy a house. It's not a bad thing - I want the house now but saving up would take too long. It's just a choice. "Repaying" technical debt is implementing the missing features, removing the temporary hacks etc. Not taking it can be an option, if you have full funding upfront for example. It's just not always the best option. Just like borrowing money, getting into some technical debt can be worthwhile.
  - mtVessel 6y ago
    Branding every possible decision as "technical debt" is intellectually dishonest. Each decision you make has consequences. Technical debt is the result of choosing an expedient path over one that supports your wider goals. It's true that there's no perfect state, but only because this is engineering, where we don't care about "perfection", only tolerances.
himinlomax 6y ago
> ...but when you have a lot of debt, lenders are cautious about lending you money That doesn't strike me as the main point of the metaphor. The more debt you have, the more borrowing becomes expensive because you have to pay interest on the total amount; it grows exponentially (in the literal meaning) if you don't repay it. As many find out the hard way, it gets to a point where adding new features or fixing bugs takes insane amounts of time because you can't make changes without breaking everything.
- vbsteven 6y ago
  This is what technical debt means to me. Decisions/shortcuts made early in the project that lead to lots of lost time when adding something new later (the lost time is the interest payment). Good examples of this are premature microservices, no good separation between modules, bad database schema design, etc...
iso1210 6y ago
I need some software to solve a business problem I have now, in 5 years time my problem might not even exist, there may be a better solution on the market, my company might not even exist - perhaps because my outgoings were all on expensive developers refactoring into the latest and greatest framework. Software is not the end goal for most businesses, it's a tool to get
- ThrowAwayqqaazz 6y ago
  I’m not sure if this is #1 a geographical-cultural thing, #2 a generational thing or #3 a natural evolution thing but I’ve been in the game from mid 1999 onwards including the Dot-com bubble (yeah get off my lawn, ok boomer etc etc). In all* the places I ‘ve done work for if there were any uncaught bugs during peer review we would be mortified (‘we’ being whichever person wrote the code) and endure a day or two of gentle ribbing from the rest of the team (sounds a bit like bullying but wasn’t). If anything we (the team) shipped had bugs in it that were discovered during client demos or even worse at the end-user stage it would be like there had been a death in the family in the department for the rest of the day. And this was at all of the places I’ve chiseled code on to clay slates in cuneiform at (ok slight exaggeration there). The point I am trying to (badly) make is - When did the attitude of ‘code fast, push it out the door and fix in v2’ become the norm? I mean, sure in my days(), there was always a massive push by sales to get stuff out the door, screaming pre-sales consultants* etc but the Lead Dev would always be the one having sufficient authority (and guts?) to say - ‘it’s ready when it’s ready and not till then’. Diplomatically of course. Perhaps the difference was in the way that project time-scales and milestones were set. We (the devs) would always double any time estimate and ‘fight hard’ to get bargained down to say 9 days down from the original ten (eg). Usually if it was ready by the 5 days it should have taken we would release it. All time budgets always included a full day allocated for the entire dev team to kick the tires on it prior to releasing anything. Consultants and Sales guys loved us (dev team) – They get their ‘toy’ early so had a few days to play around with it before the customer got it (hint, makes for a much slicker sales pitch) but also because they knew we (any team I’ve worked with or lead) took any bugs very personally. If you have never been in sales, Trust me – the inner cringe a sales guy feels as the demo app crashes is a tough thing to recover from when pitching to clients. Perhaps I just got lucky and never came across a company that moved fast and broke things. I’ve certainly politely never returned on day 2 at a few gigs based on team moral, coding style, basecode etc so who knows? Certainly I know that being able to mock competitors that released buggy code helped ease the pain of explaining why any stuff we did was 3x – 5x more expensive than the median of the ‘get three tenders’ quote price range. Ranging from government departments, an international consultancy firm, an international high net worth private bank, small (10+ employees) companies, various start-ups (mostly B2B integrators, B2C arbitrage etc), NGOs etc.etc. After that moved to RTOS running on custom chip-sets and then some on to some other fun stuff. Mention not as a boast (hence the throw-away account) but to illustrate that the teams and companies I have worked for all had very, very different cultures and mindsets. If I had no experience of a start-up environment or experience of bureaucratic orgs etc then I really couldn’t / shouldn’t / wouldn’t comment. * = when still junior enough for it to be an issue. * (what are these days called Forward Deployed Software engineers I think)
GuB-42 6y ago
I would add that technical debt by itself is not a bad thing. Just as real life debt is not a bad thing. It fact, it can be essential if you want to do anything at all. It is all about proper balance. Too little debt is inefficient, too much and you are getting overwhelmed. The metaphor for piling crap on crap would be a Ponzi scheme. You pay your debts by making bigger debts. It works as long as you find suckers, it will break down eventually.
- dllthomas 6y ago
  Technical debt by itself is a bad thing. It's just that, much as with actual debt, it's often worthwhile to accept a little bit of bad if you get a lot of good in exchange. I was going to write that there's no reason you'd want financial debt qua financial debt, and that's sort of true but I realized that credit ratings complicate things. Sometimes an important part of what you're getting in exchange for the debt (and its repayment) is capacity for borrowing more when it first-order matters in the future, by way of establishing a reputation for being able to handle debt correctly. Mapping this back to software seems interesting. I can't think of a parallel for credit reporting agencies, but it's certainly the case that a team might be more (or less) willing to take on technical debt to meet the schedule desired by a manager or a PM if there is a history of allowing them room to pay down the debt later (or failing to).
  - perl4ever 6y ago
    >I was going to write that there's no reason you'd want financial debt qua financial debt Under what circumstances? What about https://en.wikipedia.org/wiki/Time_preference https://en.wikipedia.org/wiki/Time_preference ?
    - dllthomas 6y ago
      You may want to take on debt, but it's the money you get in the short term that you want (or the stuff you spend it on, really). The debt itself, you'd prefer not to have, if everything else could be equal.
  - 6y ago
drewcoo 6y ago
Exactly this. I thought the article was struggling with the concept of metaphor.
- hajile 6y ago
  He redefines what technical debt means and then claims the new definition doesn't happen, so what other people define as technical debt must not happen either.
Kesspirar 6y ago
This depends on the situtation. Especially when writing something that doesn't have a good existing pattern (think research code). After writing something it might become clear that a everything would be better off one way or another, and adding new research features might be impossible given the current structure. This is why most packages for doing machine learning research have just turned into autograd tools. Picking any fixed structure for research code is effectively blocking off some avenue of research.
perl4ever 6y ago
It seems to me that rewriting stuff is what you do when you can't stand to maintain it, i.e. pay the interest, hence it's like declaring bankruptcy.

xixixao 6y ago

The article ignores that there are many ways to initially write code, and some are better than others. “Creating technical debt” is about not spending the time to find a good way to initially write the code, leaving it to a later point in time. This should be a cautious decision (and I’ve seen it happen many times, at individual/team/even org level). This is “tech debt”, and it does exist.

zuppy 6y ago
> is about not spending the time to find a good way to initially write the code in an ideal world, yeah, that would be the cause, but in reality there are multiple other constraints: - time constraint: you can not spend as much time as you want to make the perfect code (and that is ok, you want to ship and add value to the business so you continue to get your salary - see the extreme case of Duke Nukem Forever) - dependency constraint: sometimes other teams requirement will affect your code quality - cost constraint: again, you don’t want to go bankrupt - competency constraint: there are juniors and there are people who don’t have the knowledge to perfectly cover your requirements etc
- magicalhippo 6y ago
  There can be many very valid reasons for creating technical dept when writing code. That does not mean technical dept is not a thing or not a real issue in certain codebases. Almost every day I think about the potential technical dept of my code.
- gwd 6y ago
  Sure, and that's actually 100% normal in business -- it's called the "J-curve". Lots of businesses big and small start their lives, or even start some new project or expansion within an existing business, by borrowing money and then paying it back. The key thing is 1) borrowing money "strategically", and not just willy-nilly and 2) paying it back when you can afford to, rather than continually paying interest on it. It totally makes sense to take on technical debt in order to get your MVP out the door quickly; or to be able to fix an urgent customer issue; or to be able to make a release. And in some cases, it may make sense to keep technical debt around indefinitely. What doesn't make sense is to pile on technical debt for no real benefit, and then not take any time to pay it down. That's like always buying things on your credit card just because you can and only making the minimum payments.
rumanator 6y ago
> “Creating technical debt” is about not spending the time to find a good way to initially write the code, leaving it to a later point in time. This is the wrong way to describe and explain technical debt. It fails primarily to sell the wrong idea that technical debt results from incompetence or failure to do a good job. The truth if the matter is that in software development the absolute best solution to a problem is to provide an implementation that meets current requirements and is implemented as fast as possible. Overgeneralizing is bad code. Abstracting implementation details is a code smell. Proposing an implementation that considers additional design requirements and constraints is goldplating a solution, thus the sign of a mix of incompetence and wasted effort. But then what if requirements change? Ah, the delta between the fast and good solution for the initial problem and adapting it with quick fixes to address the new requirements is precisely where technical debt pops up.
- adrianmonk 6y ago
  You made a good argument that generalizing is an investment that often doesn't pay off. That's a separate issue from technical debt because whether code is generalized is only one aspect of many that determines whether the code is a dream or a nightmare to work with. For example, if all your variable and function names are vague and misleading because you didn't take the time to choose names that make any sense, that saved you time now and will cost you later, but it has nothing to do with generalization.
  - rumanator 6y ago
    > That's a separate issue from technical debt because whether code is generalized is only one aspect of many that determines whether the code is a dream or a nightmare to work with. That's one of the problems attributed to goldplating and over-engineering solutions. One man's future-proof implementation is another man's unnecessary indirection that's a problem to maintain. Thus we end up creating an environment where rigid implementations that are prone to colossal amounts of technical debt are preferred over adaptable solutions that minimize or eliminate technical debt.
- xixixao 6y ago

user5994461 6y ago

> You “repay” the technical debt by fixing stuff that causes problems Well, that sounds a lot like maintenance.

sixstringtheory 6y ago
Maintenance is the repayment, not the debt itself.
lucideer 6y ago
As the GP said: > The metaphor isn’t perfect But there's a difference between maintenance that fixes problems expediently and maintenance that fixes problems more permanently. The technical debt metaphor is an attempt to model the cons of doing the former too often (otherwise faster always seems better).
hajile 6y ago
Maintenance of good code is very different than going in and fixing a bunch of TODOs so the thing won't break outside the happy path.

galoisgirl 6y ago

Well said. All the smart things I ever read about technical debt basically describe debt and add the word "technical" - because that's what it is. It's not maintenance, it's not refactoring, it's just pure and simple debt.

user5994461 6y ago
It's not debt because unlike (financial) debt, there is no way to not take it or to repay it. Technical debt in software is unavoidable. Every variable and function and design decision can invariably be rebranded as technical debt soon enough. The implication of "technical debt" is that there is a perfect state to reach with no debt, but there isn't. It also implies that debt could be avoided but it can't be, it's inherent to development.
- galoisgirl 6y ago
  I'm writing this as a middle-class person, who has to go into debt if she wants to buy a house. It's not a bad thing - I want the house now but saving up would take too long. It's just a choice. "Repaying" technical debt is implementing the missing features, removing the temporary hacks etc. Not taking it can be an option, if you have full funding upfront for example. It's just not always the best option. Just like borrowing money, getting into some technical debt can be worthwhile.
- mtVessel 6y ago
  Branding every possible decision as "technical debt" is intellectually dishonest. Each decision you make has consequences. Technical debt is the result of choosing an expedient path over one that supports your wider goals. It's true that there's no perfect state, but only because this is engineering, where we don't care about "perfection", only tolerances.

himinlomax 6y ago

> ...but when you have a lot of debt, lenders are cautious about lending you money That doesn't strike me as the main point of the metaphor. The more debt you have, the more borrowing becomes expensive because you have to pay interest on the total amount; it grows exponentially (in the literal meaning) if you don't repay it. As many find out the hard way, it gets to a point where adding new features or fixing bugs takes insane amounts of time because you can't make changes without breaking everything.

vbsteven 6y ago
This is what technical debt means to me. Decisions/shortcuts made early in the project that lead to lots of lost time when adding something new later (the lost time is the interest payment). Good examples of this are premature microservices, no good separation between modules, bad database schema design, etc...

iso1210 6y ago

I need some software to solve a business problem I have now, in 5 years time my problem might not even exist, there may be a better solution on the market, my company might not even exist - perhaps because my outgoings were all on expensive developers refactoring into the latest and greatest framework. Software is not the end goal for most businesses, it's a tool to get

ThrowAwayqqaazz 6y ago
I’m not sure if this is #1 a geographical-cultural thing, #2 a generational thing or #3 a natural evolution thing but I’ve been in the game from mid 1999 onwards including the Dot-com bubble (yeah get off my lawn, ok boomer etc etc). In all* the places I ‘ve done work for if there were any uncaught bugs during peer review we would be mortified (‘we’ being whichever person wrote the code) and endure a day or two of gentle ribbing from the rest of the team (sounds a bit like bullying but wasn’t). If anything we (the team) shipped had bugs in it that were discovered during client demos or even worse at the end-user stage it would be like there had been a death in the family in the department for the rest of the day. And this was at all of the places I’ve chiseled code on to clay slates in cuneiform at (ok slight exaggeration there). The point I am trying to (badly) make is - When did the attitude of ‘code fast, push it out the door and fix in v2’ become the norm? I mean, sure in my days(), there was always a massive push by sales to get stuff out the door, screaming pre-sales consultants* etc but the Lead Dev would always be the one having sufficient authority (and guts?) to say - ‘it’s ready when it’s ready and not till then’. Diplomatically of course. Perhaps the difference was in the way that project time-scales and milestones were set. We (the devs) would always double any time estimate and ‘fight hard’ to get bargained down to say 9 days down from the original ten (eg). Usually if it was ready by the 5 days it should have taken we would release it. All time budgets always included a full day allocated for the entire dev team to kick the tires on it prior to releasing anything. Consultants and Sales guys loved us (dev team) – They get their ‘toy’ early so had a few days to play around with it before the customer got it (hint, makes for a much slicker sales pitch) but also because they knew we (any team I’ve worked with or lead) took any bugs very personally. If you have never been in sales, Trust me – the inner cringe a sales guy feels as the demo app crashes is a tough thing to recover from when pitching to clients. Perhaps I just got lucky and never came across a company that moved fast and broke things. I’ve certainly politely never returned on day 2 at a few gigs based on team moral, coding style, basecode etc so who knows? Certainly I know that being able to mock competitors that released buggy code helped ease the pain of explaining why any stuff we did was 3x – 5x more expensive than the median of the ‘get three tenders’ quote price range. Ranging from government departments, an international consultancy firm, an international high net worth private bank, small (10+ employees) companies, various start-ups (mostly B2B integrators, B2C arbitrage etc), NGOs etc.etc. After that moved to RTOS running on custom chip-sets and then some on to some other fun stuff. Mention not as a boast (hence the throw-away account) but to illustrate that the teams and companies I have worked for all had very, very different cultures and mindsets. If I had no experience of a start-up environment or experience of bureaucratic orgs etc then I really couldn’t / shouldn’t / wouldn’t comment. * = when still junior enough for it to be an issue. * (what are these days called Forward Deployed Software engineers I think)

GuB-42 6y ago

I would add that technical debt by itself is not a bad thing. Just as real life debt is not a bad thing. It fact, it can be essential if you want to do anything at all. It is all about proper balance. Too little debt is inefficient, too much and you are getting overwhelmed. The metaphor for piling crap on crap would be a Ponzi scheme. You pay your debts by making bigger debts. It works as long as you find suckers, it will break down eventually.

dllthomas 6y ago
Technical debt by itself is a bad thing. It's just that, much as with actual debt, it's often worthwhile to accept a little bit of bad if you get a lot of good in exchange. I was going to write that there's no reason you'd want financial debt qua financial debt, and that's sort of true but I realized that credit ratings complicate things. Sometimes an important part of what you're getting in exchange for the debt (and its repayment) is capacity for borrowing more when it first-order matters in the future, by way of establishing a reputation for being able to handle debt correctly. Mapping this back to software seems interesting. I can't think of a parallel for credit reporting agencies, but it's certainly the case that a team might be more (or less) willing to take on technical debt to meet the schedule desired by a manager or a PM if there is a history of allowing them room to pay down the debt later (or failing to).
- perl4ever 6y ago
  >I was going to write that there's no reason you'd want financial debt qua financial debt Under what circumstances? What about https://en.wikipedia.org/wiki/Time_preference https://en.wikipedia.org/wiki/Time_preference ?
  - dllthomas 6y ago
    You may want to take on debt, but it's the money you get in the short term that you want (or the stuff you spend it on, really). The debt itself, you'd prefer not to have, if everything else could be equal.
- 6y ago

drewcoo 6y ago

Exactly this. I thought the article was struggling with the concept of metaphor.

hajile 6y ago
He redefines what technical debt means and then claims the new definition doesn't happen, so what other people define as technical debt must not happen either.

Kesspirar 6y ago

This depends on the situtation. Especially when writing something that doesn't have a good existing pattern (think research code). After writing something it might become clear that a everything would be better off one way or another, and adding new research features might be impossible given the current structure. This is why most packages for doing machine learning research have just turned into autograd tools. Picking any fixed structure for research code is effectively blocking off some avenue of research.

perl4ever 6y ago

It seems to me that rewriting stuff is what you do when you can't stand to maintain it, i.e. pay the interest, hence it's like declaring bankruptcy.