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.
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.
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
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?
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.
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.
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.
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?
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.
> 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.
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.
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.
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.
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.
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.
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
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.