5 ms·

The Annual Cost of Technical Debt: $1.52T

21 points by d_tr 3y ago

deleted 3y ago
[deleted]
kazinator 3y ago
I think you can get almost any figure, depending on where you place the goalposts in the definition of technical debt. Two programmers who hate each other's code can call each other's code "technical debt" while extolling the virtues of their own. Operating systems, languages, run-times, editors, browsers, websites, social networks, .... that I don't use are all technical debt that should die. Don't you lay your deleting paws on what I do use, though! The term "technical debt" has about as much content as "suckage", "bloat" or "cruft". It sounds more intellectual though. It's a technical term: I mean, for Pete's sake, just look at it: it has "technical" right in it, so how can it not be! "Debt" is from finance, which gives it an air of credibility with anyone in your organization who approves expenses.
- bongodongobob 3y ago
  Tech debt is extremely easy to quantify if you're not talking about code, which in my experience, usually isn't what it's referring to.
  - hn_throwaway_99 3y ago
    This article is referring to a number from the "Consortium for Information & Software Quality", so I think it's safe to assume it refers to code.
- georgeecollins 3y ago
  So true! I used to manage a project where one star engineer would always say we needed to stop work on features and re-engineer parts of the project so it "made more sense" or "wasn't a mess." We didn't have a lot of bugs or performance issues but this person felt parts of the code base were terribly designed and slowing down development. Other star engineers sort of agreed but did not consider it as urgent. But even when we set aside time to plan it they couldn't agree on a better design for the parts of the backend / app in question. One person's refactoring would have become another's technical debt. So technical debt is certainly real but also sometimes in the eye of the beholder.
  - jamescostian 3y ago
    I think a lot of really smart people end up claiming something like "this whole system wasn't designed properly, we can do it way cleaner if we redesign it from the ground up" but it's always a trap. Incremental improvements take less time, can be more easily understood, are safer to deploy. But a lot of those really smart people have perfectionistic tendencies that cloud their judgement, and nobody can imagine all the different paper cuts that will get in the way of their beautiful vision. And thus, the new technical debt (to someone else) is written
- deleted 3y ago
  [deleted]
  - deleted 3y ago
    [deleted]
grohan 3y ago
Impressive numbers. Does anyone have any read or anecdotes on how much a small/mid/large company loses from low quality of software/bad practices (or conversely profits from the opposite)? Seems like a challenging metric to measure, but always been curious on what the numbers look like.
MPSimmons 3y ago
[flagged]
rgmerk 3y ago
These numbers smell like there’s at least one faulty assumption in there. A) How much of this debt could have been avoided with industry best practice as now understood? B) how much of this debt could have been avoided with industry best practice as understood when the software was written?
1594932281 3y ago
From the quote in the article about paying back technical debt: "Technical debt accumulates when decision-makers opt for a short-term solution to a software development problem rather than a more comprehensive long-term solution. This initially hides substantial costs that organizations must later pay." One thing to keep in mind is you don't always need to pay this debt back. For instance - what if you want to try a quick prototype of something (which may later be discarded if it doesn't pan out), or just need a temporary stopgap solution?
- willsmith72 3y ago
  and it's not just that to the bankrupt startup, the difference between $5m of tech debt and a perfect codebase/architecture is precisely 0. they're bankrupt either way racking up tech debt is a necessary strategy at certain points in most companies' lives
  - eru 3y ago
    Yes. Though keep in mind that you can crack an awful lot of eggs without making an omelette.
- ndriscoll 3y ago
  It's not just temporary or throw away code. People are quick to use the term "technical debt" to describe code that's janky but doesn't actually cause any issues or have much reason to change. If your janky code that "needs cleanup" sits at the bottom of your todo list for 8 years without needing to be touched, and meanwhile its been fulfilling its purpose the whole time, then it's not really "debt". It's a golden goose with an ugly face. Even if jank today means future changes are more expensive, if those changes are in service to growth, that just means that in the future, you'll need a capital investment if you want to grow, which is normal. It's not the same thing as debt today. You could choose to not target that growth avenue and never incur that cost. It's pretty normal to have to buy a completely a new machine to support new use-cases in the physical world, and owning an older machine doesn't make that any cheaper, and physical machines require actual ongoing costs to not literally fall apart on their own. Even software that's full of "debt" usually gives you something cheaper than having to repay the entire capital investment on a new program. If it didn't, you'd just rewrite software from scratch every time you needed something new. And software does not in fact rot over time. If you don't touch it, it generally does the exact same thing today as it did yesterday, last week, and last year. If you're happy with that, you can just leave it alone indefinitely. Web 1.0 sites continue to work just as well today as they did 20 years ago, except with much faster computers to process them. Basically, the analogy has always been pretty bad.
joevandyk 3y ago
How many trillions of value was created by taking on 1.52T in technical debt?
- itissid 3y ago
  Yeah exactly right. If the growth > 0 you can continue borrowing and keep interest rates low.
  - vlovich123 3y ago
    Only if growth > “interest rate” - if productivity growth of tech plateaus or even slows then your ability to do anything in tech probably disappears. This is the problem with pushing off all short term problems into the future indefinitely and ignoring them.
- crazygringo 3y ago
  I came here to post exactly that. Knowing the cost is irrelevant if you don't know the benefits. As long as the benefits are outweighing the costs, then everything is good. The net result of the technical debt is positive. That's not to say that technical debt never gets out of hand, just like actual debt can. But it's a tool to produce greater value in total, when used right.
- MangoCoffee 3y ago
  a lot. I do the integration for my employer. we saved a lot of manpower by automating tasks that used to be done by an employee. this mid-size company already sold twice. I highly doubt these investment firms care about technical debt. they just want to pad up the company (cut costs) and make it look good so they can flip it. we are not in IT
  - eru 3y ago
    Why doesn't the original owner pad up the company (cut costs) and sell for more in the first place?
isityouyesitsme 3y ago
Cool. What's the opportunity cost to fix it?
- xupybd 3y ago
  This is the key.
- cortesoft 3y ago
  Yeah, they mention the cost of technical debt, but they don't talk about the returns from the technical debt. How much value was created by going into technical debt? Unless we know that, we have no way of determining if it is a bad thing or not.
adhesive_wombat 3y ago
Honestly, sounds low. Technical debt is just like real debt: a useful tool to allow you to borrow against the future to get things done today, and an existential threat if not serviced before it gets out of hand. A tool that everyone else is using to the hilt and if you don't you'll be at a severe disadvantage. If it accumulates, it can sometimes be cleared down to a sustainable (and even useful) level through a painful multi-year process where no-one is having fun and you don't get to do many nice things you thing you should be able to.
monsecchris 3y ago
Technical debt is the term midwits use to describe bad code.
- xupybd 3y ago
  Not always. Sometimes you take on debt to ship faster. The same way you take on debt to grow a company faster. Bad code is often just careless or inexperienced developers producing low quality with now real upside to the company.
- shortrounddev2 3y ago
  To me the purest form of technical debt is code which may not be bad, but where you made compromises in the architecture to solve short term problems, limiting the extensibility of the code later on. The debt is paid with hours of your life, later on when you have to refactor it
  - mrits 3y ago
    What good is an architecture if you can't make compromises? I'm only half kidding
thatguysaguy 3y ago
The article definitely doesn't do the work needed to establish that we should care about the headline numbers at all. It states an estimate of how much it would cost to fix things detected by this automated system, but there's no credible estimate of how important/impactful the detected issues are.
dosinga 3y ago
Hmm, the article body says: the accumulated technical debt of software has grown to approximately $1.52 trillion So that's the total technical debt, not the cost (interest if you will) of that debt
4ndrewl 3y ago
"This initially hides substantial costs that organizations must later pay.” _May_ need to pay if the bet pays off. What about the savings from releasing fast and failing, rather than building the perfect, but wrong, solution?
mrits 3y ago
Having $0 in technical debt hasn't made me any money yet.
zwieback 3y ago
For us a big driver of technical debt is investment in long-lived industrial equipment (motors, controllers, sensors, etc.) Oftentimes the SW, especially drivers, don't keep up and keep us stuck on old platforms. It's gotten a ton better since the industry mostly moved from custom ISA,PCI,PCIe,... boards to Ethernet or USB.
androsynth89 3y ago
There are billions of dollars SAVED by strategic use of tech debt as well.
hn_throwaway_99 3y ago
This is a "lie with statistics" article. Trying to quantify "Technical Debt", at least as it applies to software, is not possible, and numbers put up here were pulled out of someone's rear end. As other commenters have mentioned, how expensive would it have been to not have incurred this technical debt in the first place? Speed matters, and there are definitely sometimes places where the wiser business decision is to incur technical debt if it allows hitting a milestone earlier. I honestly didn't want to waste time reading past "A significant portion of the current technical debt that exists today was created through “quick and dirty” development techniques (e.g., agile without software engineering discipline)." Agile (or at least some specific implementations of it) may have some problems, but trying to say it is implemented "without software engineering discipline" is laughable. Direct case in point: young folks may not be aware of this, but in the late 90s/early 00s, the "Software Capability Maturity Model" (CMM) was all the rage. It was focused essentially on process repeatability, and some companies strived to hit "CMM Level 5". It was an especially popular model in India. And you know what? None of the tech companies who became billion dollar behemoths over the past 2 decades were the ones who focused on this type of "software engineering discipline". They were the ones that made the right business tradeoffs for the issues at hand.
quickthrower2 3y ago
What would be the cost of not having said software?
geekjock 3y ago
> One of the main challenges when dealing with technical debt has been the lack of a way to measure it. To help overcome that problem, CISQ/OMG led the development of an Automated Technical Debt (ATD) measurement standard, which is currently being updated with a new version expected in 2023. I'm highly skeptical about the tech debt measurement algorithm this article purports to be developing. Google researchers recently published a paper on their attempts to measure technical debt. They tested 117 metrics that were proposed as potential indicators. Regressions were used to test each metric to see whether it could predict an engineer’s perceptions of technical debt. No single metric or combination of metrics were found to be valid indicators.

21 points by d_tr 3y ago

deleted 3y ago

[deleted]

I think you can get almost any figure, depending on where you place the goalposts in the definition of technical debt. Two programmers who hate each other's code can call each other's code "technical debt" while extolling the virtues of their own. Operating systems, languages, run-times, editors, browsers, websites, social networks, .... that I don't use are all technical debt that should die. Don't you lay your deleting paws on what I do use, though! The term "technical debt" has about as much content as "suckage", "bloat" or "cruft". It sounds more intellectual though. It's a technical term: I mean, for Pete's sake, just look at it: it has "technical" right in it, so how can it not be! "Debt" is from finance, which gives it an air of credibility with anyone in your organization who approves expenses.

bongodongobob 3y ago
Tech debt is extremely easy to quantify if you're not talking about code, which in my experience, usually isn't what it's referring to.
- hn_throwaway_99 3y ago
  This article is referring to a number from the "Consortium for Information & Software Quality", so I think it's safe to assume it refers to code.
georgeecollins 3y ago
So true! I used to manage a project where one star engineer would always say we needed to stop work on features and re-engineer parts of the project so it "made more sense" or "wasn't a mess." We didn't have a lot of bugs or performance issues but this person felt parts of the code base were terribly designed and slowing down development. Other star engineers sort of agreed but did not consider it as urgent. But even when we set aside time to plan it they couldn't agree on a better design for the parts of the backend / app in question. One person's refactoring would have become another's technical debt. So technical debt is certainly real but also sometimes in the eye of the beholder.
- jamescostian 3y ago
  I think a lot of really smart people end up claiming something like "this whole system wasn't designed properly, we can do it way cleaner if we redesign it from the ground up" but it's always a trap. Incremental improvements take less time, can be more easily understood, are safer to deploy. But a lot of those really smart people have perfectionistic tendencies that cloud their judgement, and nobody can imagine all the different paper cuts that will get in the way of their beautiful vision. And thus, the new technical debt (to someone else) is written
deleted 3y ago
[deleted]
- deleted 3y ago
  [deleted]

grohan 3y ago

Impressive numbers. Does anyone have any read or anecdotes on how much a small/mid/large company loses from low quality of software/bad practices (or conversely profits from the opposite)? Seems like a challenging metric to measure, but always been curious on what the numbers look like.

MPSimmons 3y ago

[flagged]

rgmerk 3y ago

These numbers smell like there’s at least one faulty assumption in there. A) How much of this debt could have been avoided with industry best practice as now understood? B) how much of this debt could have been avoided with industry best practice as understood when the software was written?

1594932281 3y ago

From the quote in the article about paying back technical debt: "Technical debt accumulates when decision-makers opt for a short-term solution to a software development problem rather than a more comprehensive long-term solution. This initially hides substantial costs that organizations must later pay." One thing to keep in mind is you don't always need to pay this debt back. For instance - what if you want to try a quick prototype of something (which may later be discarded if it doesn't pan out), or just need a temporary stopgap solution?

willsmith72 3y ago
and it's not just that to the bankrupt startup, the difference between $5m of tech debt and a perfect codebase/architecture is precisely 0. they're bankrupt either way racking up tech debt is a necessary strategy at certain points in most companies' lives
- eru 3y ago
  Yes. Though keep in mind that you can crack an awful lot of eggs without making an omelette.
ndriscoll 3y ago
It's not just temporary or throw away code. People are quick to use the term "technical debt" to describe code that's janky but doesn't actually cause any issues or have much reason to change. If your janky code that "needs cleanup" sits at the bottom of your todo list for 8 years without needing to be touched, and meanwhile its been fulfilling its purpose the whole time, then it's not really "debt". It's a golden goose with an ugly face. Even if jank today means future changes are more expensive, if those changes are in service to growth, that just means that in the future, you'll need a capital investment if you want to grow, which is normal. It's not the same thing as debt today. You could choose to not target that growth avenue and never incur that cost. It's pretty normal to have to buy a completely a new machine to support new use-cases in the physical world, and owning an older machine doesn't make that any cheaper, and physical machines require actual ongoing costs to not literally fall apart on their own. Even software that's full of "debt" usually gives you something cheaper than having to repay the entire capital investment on a new program. If it didn't, you'd just rewrite software from scratch every time you needed something new. And software does not in fact rot over time. If you don't touch it, it generally does the exact same thing today as it did yesterday, last week, and last year. If you're happy with that, you can just leave it alone indefinitely. Web 1.0 sites continue to work just as well today as they did 20 years ago, except with much faster computers to process them. Basically, the analogy has always been pretty bad.

joevandyk 3y ago

How many trillions of value was created by taking on 1.52T in technical debt?

itissid 3y ago
Yeah exactly right. If the growth > 0 you can continue borrowing and keep interest rates low.
- vlovich123 3y ago
  Only if growth > “interest rate” - if productivity growth of tech plateaus or even slows then your ability to do anything in tech probably disappears. This is the problem with pushing off all short term problems into the future indefinitely and ignoring them.
crazygringo 3y ago
I came here to post exactly that. Knowing the cost is irrelevant if you don't know the benefits. As long as the benefits are outweighing the costs, then everything is good. The net result of the technical debt is positive. That's not to say that technical debt never gets out of hand, just like actual debt can. But it's a tool to produce greater value in total, when used right.
MangoCoffee 3y ago
a lot. I do the integration for my employer. we saved a lot of manpower by automating tasks that used to be done by an employee. this mid-size company already sold twice. I highly doubt these investment firms care about technical debt. they just want to pad up the company (cut costs) and make it look good so they can flip it. we are not in IT
- eru 3y ago
  Why doesn't the original owner pad up the company (cut costs) and sell for more in the first place?

isityouyesitsme 3y ago

Cool. What's the opportunity cost to fix it?

xupybd 3y ago
This is the key.
cortesoft 3y ago
Yeah, they mention the cost of technical debt, but they don't talk about the returns from the technical debt. How much value was created by going into technical debt? Unless we know that, we have no way of determining if it is a bad thing or not.

adhesive_wombat 3y ago

Honestly, sounds low. Technical debt is just like real debt: a useful tool to allow you to borrow against the future to get things done today, and an existential threat if not serviced before it gets out of hand. A tool that everyone else is using to the hilt and if you don't you'll be at a severe disadvantage. If it accumulates, it can sometimes be cleared down to a sustainable (and even useful) level through a painful multi-year process where no-one is having fun and you don't get to do many nice things you thing you should be able to.

monsecchris 3y ago

Technical debt is the term midwits use to describe bad code.

xupybd 3y ago
Not always. Sometimes you take on debt to ship faster. The same way you take on debt to grow a company faster. Bad code is often just careless or inexperienced developers producing low quality with now real upside to the company.
shortrounddev2 3y ago
To me the purest form of technical debt is code which may not be bad, but where you made compromises in the architecture to solve short term problems, limiting the extensibility of the code later on. The debt is paid with hours of your life, later on when you have to refactor it
- mrits 3y ago
  What good is an architecture if you can't make compromises? I'm only half kidding

thatguysaguy 3y ago

The article definitely doesn't do the work needed to establish that we should care about the headline numbers at all. It states an estimate of how much it would cost to fix things detected by this automated system, but there's no credible estimate of how important/impactful the detected issues are.

dosinga 3y ago

Hmm, the article body says: the accumulated technical debt of software has grown to approximately $1.52 trillion So that's the total technical debt, not the cost (interest if you will) of that debt

4ndrewl 3y ago

"This initially hides substantial costs that organizations must later pay.” _May_ need to pay if the bet pays off. What about the savings from releasing fast and failing, rather than building the perfect, but wrong, solution?

mrits 3y ago

Having $0 in technical debt hasn't made me any money yet.

zwieback 3y ago

For us a big driver of technical debt is investment in long-lived industrial equipment (motors, controllers, sensors, etc.) Oftentimes the SW, especially drivers, don't keep up and keep us stuck on old platforms. It's gotten a ton better since the industry mostly moved from custom ISA,PCI,PCIe,... boards to Ethernet or USB.

androsynth89 3y ago

There are billions of dollars SAVED by strategic use of tech debt as well.

hn_throwaway_99 3y ago

This is a "lie with statistics" article. Trying to quantify "Technical Debt", at least as it applies to software, is not possible, and numbers put up here were pulled out of someone's rear end. As other commenters have mentioned, how expensive would it have been to not have incurred this technical debt in the first place? Speed matters, and there are definitely sometimes places where the wiser business decision is to incur technical debt if it allows hitting a milestone earlier. I honestly didn't want to waste time reading past "A significant portion of the current technical debt that exists today was created through “quick and dirty” development techniques (e.g., agile without software engineering discipline)." Agile (or at least some specific implementations of it) may have some problems, but trying to say it is implemented "without software engineering discipline" is laughable. Direct case in point: young folks may not be aware of this, but in the late 90s/early 00s, the "Software Capability Maturity Model" (CMM) was all the rage. It was focused essentially on process repeatability, and some companies strived to hit "CMM Level 5". It was an especially popular model in India. And you know what? None of the tech companies who became billion dollar behemoths over the past 2 decades were the ones who focused on this type of "software engineering discipline". They were the ones that made the right business tradeoffs for the issues at hand.

quickthrower2 3y ago

What would be the cost of not having said software?

geekjock 3y ago

> One of the main challenges when dealing with technical debt has been the lack of a way to measure it. To help overcome that problem, CISQ/OMG led the development of an Automated Technical Debt (ATD) measurement standard, which is currently being updated with a new version expected in 2023. I'm highly skeptical about the tech debt measurement algorithm this article purports to be developing. Google researchers recently published a paper on their attempts to measure technical debt. They tested 117 metrics that were proposed as potential indicators. Regressions were used to test each metric to see whether it could predict an engineer’s perceptions of technical debt. No single metric or combination of metrics were found to be valid indicators.