đź”— Analysis | The Invisible $1.52 Trillion Problem: Clunky Old Software - The Wall Street Journal:
Technical debt manifests in myriad ways, from system failures and slower innovation, to security breaches. It was behind the cancellation of more than 13,000 Southwest Airlines flights in late December 2022, which stranded passengers and bags all over the U.S. during the height of the holiday travel season. It’s also, according to experts, a primary driver of the many software vulnerabilities which led to dozens of hacks in the past 12 months, including exploits of critical systems operated by Google, Apple and Microsoft.
This technical debt would require $1.52 trillion to fix, and costs the U.S. $2.41 trillion a year in cybersecurity and operational failures, failed development projects, and maintenance of outdated systems, according to a 2022 report by a software industry-funded nonprofit. That’s more than 2.5 times what the U.S. government pays in annual interest on the national debt. The author of that report, retired University of Texas at Austin software engineering professor Herb Krasner, says he believes that debt has now climbed to nearly $2 trillion.
Having worked in IT and application hosting for a few decades now, I am not at all surprised by these number. If anything, I’d be they are low, since most tech leaders tend to underestimate or deliberately downplay the amount of technical debt they are carrying.
Farther down, the article notes that reducing technical debt is challenging because companies “may be willing to spend on building new technical capabilities, but shy away from paying for work that doesn’t necessarily bring them anything new.” That is true but I think it misses a critical factor.
I have definitely seen product roadmap-based aversion to fixing broken old stuff rather than building fancy new stuff and yes, this pattern tends to get most of the blame. At a deeper level, though, companies are financially disincentivized to invest in reducing technical debt by how the funding that supports this work is accounted for.
If you’re spending money to build new product, you get to spread the cost that you track on the books out over the presumed lifespan of the product; so if you spend $1 million this year to build a new thing and you say that thing will last, say, three years, only one third of that $1M cost shows up on your books this year. However, if you’re spending that same amount of money to fix and patch an existing system, the entire $1M hits your books—and therefore your bottom line—this year.
So not only is fixing broken old stuff is not as exciting as the shiny new ball, it is less attractive financially. Ideally, leadership would be concerned about this stuff building and building, but deferring new product in favor of longer-term investments in security and stability cuts against the short-term focus on share price and growth.
Until, of course, the years-old security vulnerability in some core system gets exploited or your rickety data queueing infrastructure that has no one left supporting it finally falls over and all of your stuff is suddenly on fire. Then everyone panics and wonders how this could have happened.