5 ms·

The thing I like about “technical debt” that I haven’t seen any other terms capture is that, like financial debt, it is a tool. If you’re building a new feature

The thing I like about “technical debt” that I haven’t seen any other terms capture is that, like financial debt, it is a tool. If you’re building a new feature, there’s often a choice between doing it “right” and doing it “quick”. And it’s not a choice with a correct answer. If it’s important to get the feature to market ASAP, it might make sense to build it quickly even though you’ll have to refactor it in the future! Calling it “bad code” definitely misses the mark. IMO, it’s code that constrains you from doing things you want to do. Tech debt is almost always code that is tightly coupled to other code, which is why getting rid of it or working in codebases with a lot of it can be difficult. The key is that (again, like financial debt) you need a plan to pay technical debt down. If there’s too much, you start drowning in it. And not all of it is a choice — sometimes things unexpectedly change and current code becomes a liability. But framing technical debt in architectural decisions as a tool and a choice has helped me understand better how to accomplish business objectives as an engineer.

joyfylbanana 4y ago
The biggest difference is, that with financial debt you basically always have to pay it back in a way or another. With technical debt in startup context, it happens very often that you don't have to pay it back (failures). It is quite logical why startup founders prefer to have technical debt, as the venture is risky in any case it is the kind of liability that you only have to pay if you are successful.
- jandrese 4y ago
  Also, sometimes the things that developers consider "technical debt" end up working just fine and don't cause that much trouble. There is always the urge to build something "the right way" where it's fully modular and extensible, but if you never need to extend something the additional layers of abstraction end up being more of a hindrance than a help. There is a certain level of efficiency in building things the cheap and easy way by default and only rewriting the parts where it was actually a problem.
  - Swizec 4y ago
    Layers of abstraction are the most common type of technical debt.
  - bryanlarsen 4y ago
    Exactly. I've seen developers reduce technical debt in a way that others consider to be an increase in technical debt. One developer can add abstractions, modularity and extensibility to a code to reduce technical debt. Another developer can strip out unneeded abstractions, modularity and extensibility to reduce technical debt.
    - ClumsyPilot 4y ago
      Most developers cannot know ahead of time if a goven piece of code needs to be entensible. Often noone does
- vorpalhex 4y ago
  If you go bankrupt you don't have to pay back your financial debt either...
- marcosdumay 4y ago
  > with financial debt you basically always have to pay it back in a way or another Defaults exist. You don't always have to pay financial debt, and the case you described for technical debt is one of the main cases when people don't pay financial debts either. IMO the biggest difference is that the carrying costs of technical debt are quite random. But people say that all the time already, and it's well known that they behave more like generic liabilities instead of debts in particular.
- plorkyeran 4y ago
  Most startups shut down without ever having recouped the money which was invested in them. It's very unusual for a startup to fail without being in financial debt as most people will choose to keep trying to make things work until the money runs out.
mcbits 4y ago
Another similarity with financial debt is that a large enough entity can just keep marching on, taking on more and more debt to fuel growth for a surprisingly long time before it all collapses.
- TheRealDunkirk 4y ago
  Like the famous image of the guy who's sitting next to a pretty girl, straining to supposedly hold a fart, I can't NOT mention this. I work for a blue chip Fortune 250. We write software for a computer embedded in our products. This software is broken up into 8 pieces, which are reduced to the least-common parts. Every database, application, and workflow in the company has to deal with possibly 8 different part numbers when referring to a release of software. From the mainframe, to the PDM to the ERP to every single ad-hoc Excel spreadsheet used by every department to help manage the complexity. Most of the parts are shared across various builds, with 2 or 3 of the "subfiles" being different. So, in a release of hundreds of various custom softwares for a particular hardware product, there are hundreds-times-5-to-8 subfiles released. Each software must be broken apart, checked for commonality, and rebuilt using the common files, and then checked against the base build to make sure that it rebuilt correctly. Each release of software requires LITERALLY DAYS of work to do this, even with Excel macros. I wrote software to automate all of this. It took a half an hour, with NO manual intervention. It was strangled in the crib. WHY do we do this? Before WAN's became de rigueur, we took our software to the computer on the production lines that programs the embedded computers on floppy disks, and the software had to be broken up into 8 parts so that it would... fit on a floppy. We operate with a built-in technical debt that hasn't been needed for 30 years which would literally break the company to address. It's virtually unseen at this point. If there's a worse example of "technical debt," I'd love to hear it.
  - IsaacL 4y ago
    I'm very interested in stories like this. > I wrote software to automate all of this. It took a half an hour, with NO manual intervention. It was strangled in the crib. Can you say any more about why management at your company decided to strangle this project in the crib? What exactly happened? If you tried to pushback, how did they shut you down? If you have time I'd also be curious to hear an outline of how your solution fixed things.
Jensson 4y ago
Technical debt is like organizational debt. Organizational debt often gets you promoted, create a large department full of bad practices and you could become a director. Is organizational or technical debt good for the company? No. Is it good for the individuals creating it? Oftentimes yes, they never have to pay it back, they get to hire someone to deal with the mess instead.
- drcongo 4y ago
  That's roughly how the tory party in the UK operates.
- pimterry 4y ago
  > Is organizational or technical debt good for the company? No. Is it good for the individuals creating it? Oftentimes yes While technical debt in itself is not a good thing, choosing to take on tech debt in return for delivering quicker (getting faster feedback/not investing in an implementation too early/not over-architecting before you have real-world impact) can certainly be the right choice for the organization as a whole. I don't buy the argument that tech debt is purely a selfish choice for personal benefit.
  - Jensson 4y ago
    Can you be too thin? Yes, but most people have problem with eating too much, not too little. Same with technical and organizational debt, places taking on too little debt isn't a situation worth talking about since it is so rare. Much more likely people are motivating their poor choices since yes, in some cases it is worth taking out, but when you are already obese then eating another pie isn't going to help you stay healthy.
- resters 4y ago
  The parent got downvoted probably because of the cynical tone of the comment, but organizational / management debt is real just like tech debt. Hiring someone fresh out of college who has no experience to run an important part of a startup is a risky move that sometimes pays off and sometimes backfires. If startups were staffed only by experienced workers, some aspects would go more smoothly, but costs would be much higher. Arguably YC's value prop to downstream investors is its ability to find superb teams early and invest when doing so is cheap.
Zealotux 4y ago
Exact, to most people _debt_ equates to _risk_, but in companies and governments, debt used wisely is a powerful leverage.
kybernetikos 4y ago
> If you’re building a new feature, there’s often a choice between doing it “right” and doing it “quick”. It's really surprising how often the “quick” approach turns out to be slower than the “right” approach. Now sure, there's such a thing as focusing too much on non-market relevant aspects of a project, or going down rabbit holes, or designing and coding for a future that will almost certainly never come, but it still continues to surprise me how often when the choice is between "quick" or "right", that "quick" actually turns surprisingly soon into slow. There's a saying apparently in use in the military "slow is smooth, smooth is fast". That's the kind of wisdom we need to aim for in software engineering. "More haste, less speed". Oh yeah, the other difference is that there's no external force that will take you to court if you don't pay down technical debt, so in fact most organisations are terrible at paying it down. If you don't literally have a plan on the calendar with names and dates committed to improve the code, you're most likely fooling yourself by calling it technical debt. The true metaphor is much closer to 'Superfund site'.
- resters 4y ago
  > It's really surprising how often the “quick” approach turns out to be slower than the “right” approach. It depends on what is done fast and what is done more thoughtfully. For example, if the general architecture is thought through carefully, individual modules can be built more hastily and later rewritten. On the other hand if the architecture is unsuitable for the problem, then it matters little how well tested or high quality any of the code is, and overdoing code quality will be a waste of time. It comes down to judgment and tradeoffs (like everything in engineering). I like the concept of tech debt because it is a way of describing a class of tradeoffs.
- pif 4y ago
  > It's really surprising how often the “quick” approach turns out to be slower than the “right” approach. And it's really surprising how few people realise that, even if the "quick" approach is slower in the long term, time is not always worth the same! Time just before release is precious. Just after release, instead, you are both tired anyway and still have your code in your head, so that is the right time to refactor. In the end, technical debt, code quality, and whatever code metric... they only make sense for code that has been shipped. The code you are refining is worth nothing if users are not already using it.
vladf 4y ago
In The Hard Thing About Hard Things, Ben Horowitz purposes exactly this definition.
ilyt 4y ago
I think it stems from people not really clued in into financials and assume debt is bad and not just a tool to make more money. Which is essentially is for non-businessmen, you take on debt to get the thing you want now, not later, vs businessess, which take on debt now to make more money now
remram 4y ago
Debt is not a tool to everybody. A lot of individuals don't enter it on purpose and struggle to get rid of it. Just like technical debt. I think it's a great term.
isk517 4y ago
The other advantage I've noticed occasionally when choosing to do something "quick" over doing it "right" is that the feature in question may not have any actual demand behind it. Nothing worse than spending months working on something that it turned out nobody really wanted/needed.
Fire-Dragon-DoL 4y ago
Except that financial debt has a number, so it is really a tool, while technical debt has none, it's thin air. That's why instead of being used as a tool, it's mostly ignored, or not weighted properly
deleted 4y ago
[deleted]
taylodl 4y ago
You need a plan to pay down technical debt - because it carries interest. In this case the interest is payed by slowing down the development of new features. Also, paying the interest, i.e. incurring slower and slower new feature development costs, doesn't touch the debt principle. This is why we adopted the concept of technical debt, the term encompasses much, more more than just "bad code."

joyfylbanana 4y ago

The biggest difference is, that with financial debt you basically always have to pay it back in a way or another. With technical debt in startup context, it happens very often that you don't have to pay it back (failures). It is quite logical why startup founders prefer to have technical debt, as the venture is risky in any case it is the kind of liability that you only have to pay if you are successful.

jandrese 4y ago
Also, sometimes the things that developers consider "technical debt" end up working just fine and don't cause that much trouble. There is always the urge to build something "the right way" where it's fully modular and extensible, but if you never need to extend something the additional layers of abstraction end up being more of a hindrance than a help. There is a certain level of efficiency in building things the cheap and easy way by default and only rewriting the parts where it was actually a problem.
- Swizec 4y ago
  Layers of abstraction are the most common type of technical debt.
- bryanlarsen 4y ago
  Exactly. I've seen developers reduce technical debt in a way that others consider to be an increase in technical debt. One developer can add abstractions, modularity and extensibility to a code to reduce technical debt. Another developer can strip out unneeded abstractions, modularity and extensibility to reduce technical debt.
  - ClumsyPilot 4y ago
    Most developers cannot know ahead of time if a goven piece of code needs to be entensible. Often noone does
vorpalhex 4y ago
If you go bankrupt you don't have to pay back your financial debt either...
marcosdumay 4y ago
> with financial debt you basically always have to pay it back in a way or another Defaults exist. You don't always have to pay financial debt, and the case you described for technical debt is one of the main cases when people don't pay financial debts either. IMO the biggest difference is that the carrying costs of technical debt are quite random. But people say that all the time already, and it's well known that they behave more like generic liabilities instead of debts in particular.
plorkyeran 4y ago
Most startups shut down without ever having recouped the money which was invested in them. It's very unusual for a startup to fail without being in financial debt as most people will choose to keep trying to make things work until the money runs out.

mcbits 4y ago

Another similarity with financial debt is that a large enough entity can just keep marching on, taking on more and more debt to fuel growth for a surprisingly long time before it all collapses.

TheRealDunkirk 4y ago
Like the famous image of the guy who's sitting next to a pretty girl, straining to supposedly hold a fart, I can't NOT mention this. I work for a blue chip Fortune 250. We write software for a computer embedded in our products. This software is broken up into 8 pieces, which are reduced to the least-common parts. Every database, application, and workflow in the company has to deal with possibly 8 different part numbers when referring to a release of software. From the mainframe, to the PDM to the ERP to every single ad-hoc Excel spreadsheet used by every department to help manage the complexity. Most of the parts are shared across various builds, with 2 or 3 of the "subfiles" being different. So, in a release of hundreds of various custom softwares for a particular hardware product, there are hundreds-times-5-to-8 subfiles released. Each software must be broken apart, checked for commonality, and rebuilt using the common files, and then checked against the base build to make sure that it rebuilt correctly. Each release of software requires LITERALLY DAYS of work to do this, even with Excel macros. I wrote software to automate all of this. It took a half an hour, with NO manual intervention. It was strangled in the crib. WHY do we do this? Before WAN's became de rigueur, we took our software to the computer on the production lines that programs the embedded computers on floppy disks, and the software had to be broken up into 8 parts so that it would... fit on a floppy. We operate with a built-in technical debt that hasn't been needed for 30 years which would literally break the company to address. It's virtually unseen at this point. If there's a worse example of "technical debt," I'd love to hear it.
- IsaacL 4y ago
  I'm very interested in stories like this. > I wrote software to automate all of this. It took a half an hour, with NO manual intervention. It was strangled in the crib. Can you say any more about why management at your company decided to strangle this project in the crib? What exactly happened? If you tried to pushback, how did they shut you down? If you have time I'd also be curious to hear an outline of how your solution fixed things.

Jensson 4y ago

Technical debt is like organizational debt. Organizational debt often gets you promoted, create a large department full of bad practices and you could become a director. Is organizational or technical debt good for the company? No. Is it good for the individuals creating it? Oftentimes yes, they never have to pay it back, they get to hire someone to deal with the mess instead.

drcongo 4y ago
That's roughly how the tory party in the UK operates.
pimterry 4y ago
> Is organizational or technical debt good for the company? No. Is it good for the individuals creating it? Oftentimes yes While technical debt in itself is not a good thing, choosing to take on tech debt in return for delivering quicker (getting faster feedback/not investing in an implementation too early/not over-architecting before you have real-world impact) can certainly be the right choice for the organization as a whole. I don't buy the argument that tech debt is purely a selfish choice for personal benefit.
- Jensson 4y ago
  Can you be too thin? Yes, but most people have problem with eating too much, not too little. Same with technical and organizational debt, places taking on too little debt isn't a situation worth talking about since it is so rare. Much more likely people are motivating their poor choices since yes, in some cases it is worth taking out, but when you are already obese then eating another pie isn't going to help you stay healthy.
resters 4y ago
The parent got downvoted probably because of the cynical tone of the comment, but organizational / management debt is real just like tech debt. Hiring someone fresh out of college who has no experience to run an important part of a startup is a risky move that sometimes pays off and sometimes backfires. If startups were staffed only by experienced workers, some aspects would go more smoothly, but costs would be much higher. Arguably YC's value prop to downstream investors is its ability to find superb teams early and invest when doing so is cheap.

Zealotux 4y ago

Exact, to most people _debt_ equates to _risk_, but in companies and governments, debt used wisely is a powerful leverage.

kybernetikos 4y ago

> If you’re building a new feature, there’s often a choice between doing it “right” and doing it “quick”. It's really surprising how often the “quick” approach turns out to be slower than the “right” approach. Now sure, there's such a thing as focusing too much on non-market relevant aspects of a project, or going down rabbit holes, or designing and coding for a future that will almost certainly never come, but it still continues to surprise me how often when the choice is between "quick" or "right", that "quick" actually turns surprisingly soon into slow. There's a saying apparently in use in the military "slow is smooth, smooth is fast". That's the kind of wisdom we need to aim for in software engineering. "More haste, less speed". Oh yeah, the other difference is that there's no external force that will take you to court if you don't pay down technical debt, so in fact most organisations are terrible at paying it down. If you don't literally have a plan on the calendar with names and dates committed to improve the code, you're most likely fooling yourself by calling it technical debt. The true metaphor is much closer to 'Superfund site'.

resters 4y ago
> It's really surprising how often the “quick” approach turns out to be slower than the “right” approach. It depends on what is done fast and what is done more thoughtfully. For example, if the general architecture is thought through carefully, individual modules can be built more hastily and later rewritten. On the other hand if the architecture is unsuitable for the problem, then it matters little how well tested or high quality any of the code is, and overdoing code quality will be a waste of time. It comes down to judgment and tradeoffs (like everything in engineering). I like the concept of tech debt because it is a way of describing a class of tradeoffs.
pif 4y ago
> It's really surprising how often the “quick” approach turns out to be slower than the “right” approach. And it's really surprising how few people realise that, even if the "quick" approach is slower in the long term, time is not always worth the same! Time just before release is precious. Just after release, instead, you are both tired anyway and still have your code in your head, so that is the right time to refactor. In the end, technical debt, code quality, and whatever code metric... they only make sense for code that has been shipped. The code you are refining is worth nothing if users are not already using it.

vladf 4y ago

In The Hard Thing About Hard Things, Ben Horowitz purposes exactly this definition.

ilyt 4y ago

I think it stems from people not really clued in into financials and assume debt is bad and not just a tool to make more money. Which is essentially is for non-businessmen, you take on debt to get the thing you want now, not later, vs businessess, which take on debt now to make more money now

remram 4y ago

Debt is not a tool to everybody. A lot of individuals don't enter it on purpose and struggle to get rid of it. Just like technical debt. I think it's a great term.

isk517 4y ago

The other advantage I've noticed occasionally when choosing to do something "quick" over doing it "right" is that the feature in question may not have any actual demand behind it. Nothing worse than spending months working on something that it turned out nobody really wanted/needed.

Fire-Dragon-DoL 4y ago

Except that financial debt has a number, so it is really a tool, while technical debt has none, it's thin air. That's why instead of being used as a tool, it's mostly ignored, or not weighted properly

deleted 4y ago

[deleted]

taylodl 4y ago

You need a plan to pay down technical debt - because it carries interest. In this case the interest is payed by slowing down the development of new features. Also, paying the interest, i.e. incurring slower and slower new feature development costs, doesn't touch the debt principle. This is why we adopted the concept of technical debt, the term encompasses much, more more than just "bad code."