The Annual Cost of Technical Debt: $1.52T
itzareyesmx.medium.com
itzareyesmx.medium.com
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.
So technical debt is certainly real but also sometimes in the eye of the beholder.
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?
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
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.
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.)
This is the problem with pushing off all short term problems into the future indefinitely and ignoring them.
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.
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
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.
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?
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.
_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?
Seems like a challenging metric to measure, but always been curious on what the numbers look like.
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
Bad code is often just careless or inexperienced developers producing low quality with now real upside to the company.
The debt is paid with hours of your life, later on when you have to refactor it