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

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.