The Annual Cost of Technical Debt: $1.52T(itzareyesmx.medium.com)
itzareyesmx.medium.com
The Annual Cost of Technical Debt: $1.52T
https://itzareyesmx.medium.com/the-annual-cost-of-technical-debt-1-52-trillion-65afaa1e0005
41 コメント
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.
So technical debt is certainly real but also sometimes in the eye of the beholder.
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](1)
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.
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.
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?
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?
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
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
Yes. Though keep in mind that you can crack an awful lot of eggs without making an omelette.
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.
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.
Yes, that's why technical debt is a misnomer.
If you want a financial analogy, you should call it 'technical equity'. From a companies point of view both equity and debt are something you use to finance your business. But equity is only worth something if your company takes off. Similarly, 'technical debt' is only a problem when your software project goes somewhere.
(We are ignoring bankruptcy here.)
If you want a financial analogy, you should call it 'technical equity'. From a companies point of view both equity and debt are something you use to finance your business. But equity is only worth something if your company takes off. Similarly, 'technical debt' is only a problem when your software project goes somewhere.
(We are ignoring bankruptcy here.)
How many trillions of value was created by taking on 1.52T in technical debt?
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
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
Why doesn't the original owner pad up the company (cut costs) and sell for more in the first place?
what makes you think they didn't?
They might have done some of that, but obviously the second owner founds some more opportunities. To reformulate my question: why didn't owner n anticipate all the padding that owner n+1 was about to do, and sell directly to owner n+2 at the higher price that owner n+1 got?
Yeah exactly right. If the growth > 0 you can continue borrowing and keep interest rates low.
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.
This is the problem with pushing off all short term problems into the future indefinitely and ignoring them.
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.
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.
> 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.
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.
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.
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?
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?
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.
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.
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.
"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?
_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?
[deleted]
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.
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.
Seems like a challenging metric to measure, but always been curious on what the numbers look like.
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
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
Cool. What's the opportunity cost to fix it?
There are billions of dollars SAVED by strategic use of tech debt as well.
Having $0 in technical debt hasn't made me any money yet.
What would be the cost of not having said software?
Technical debt is the term midwits use to describe bad code.
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
The debt is paid with hours of your life, later on when you have to refactor it
What good is an architecture if you can't make compromises? I'm only half kidding
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.
Bad code is often just careless or inexperienced developers producing low quality with now real upside to the company.
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.