Most of us have heard the term “debt crisis.” A debt crisis happens when a country, a business, or sometimes an individual has borrowed so much money that it can’t repay its debts on time or perhaps at all. It usually triggers serious financial and economic problems that can range from currency devaluation, inflation, or the imposition of austerity measures through to recession or even economic depression.
Debt crises are generally “no bueno” for anyone involved. However, you may not be aware of the equivalent situation in the world of software engineering, which is termed “Technical Debt,” or TD. This is a software development metaphor that refers to the cost of choosing a quick or easy technical approach or solution now instead of a better, more time-consuming one, which will in due course require “repayment” in the form of refactoring, fixing, or extra work later on.
TD is one of those invisible issues that organizations either realize that they have a problem with, and so can plan to do something about it, or they don’t know, and that’s worse. It generally arises because it’s faster, cheaper, and easier to put things off until a future date, rather than dealing with them now, but refactoring the relevant code.
Refactoring and the Nature of Technical Debt
Refactoring is the term used in software when restructuring of existing code is undertaken without changing its external behavior. The goal is to improve the code’s internal structure, making it cleaner, more readable, more maintainable, and often more efficient while ensuring it still performs the same functions.
Refactoring is like paying interest, whereby you make small, consistent, and continuous improvements to prevent TD from growing in quantity or seriousness. Simply put, TD is the extra work you’ll have to do in the future because you took shortcuts today. It is analogous to the idea of borrowing today to spend tomorrow and end up paying for that choice for many years to come. TD is often created as a byproduct to meet a deadline, perhaps by hardcoding something instead of building a flexible, reusable code module. That could be termed “deliberate” technical debt; it works for now, but when requirements change later, it’s a pain to update, and that pain is your technical debt coming due. “Accidental” technical debt, on the other hand, is debt that accumulates through knowledge gaps, poor practices, or lack of documentation. This type typically carries higher long-term costs.
Recognising When Technical Debt Becomes a Problem
There are signs when TD starts to become an issue in an organization. These include, but are not limited to, the following:
– New features take significantly longer than expected to deliver.
– Changes made to one area create bugs in unrelated parts of the system.
– Developers have to avoid touching certain parts of the code for fear of breaking things.
– Test coverage, by which we mean the footprint of software tests, is poor or outdated.
Essentially, when the cost of change rises and momentum slows, technical debt may be to blame. However, TD is a natural byproduct of any iterative, evolutionary process like software development, and it’s not inherently a bad thing. In fact, it can be a strategic trade-off and a part of the cost of doing business when teams want to deliver features to get early and frequent user feedback before investing further in that area of the system. The real problem arises when technical debt is left unaddressed over time, allowing it to accumulate unchecked. Like financial debt, it can grow to a point where the “interest”, the extra effort needed to work around it, becomes overwhelming. Eventually, you may find yourself spending more time managing the consequences of the debt than delivering new value. At that point, repayment can feel impossible, and the situation escalates into a full-blown crisis with systems failing either partially or completely.
How Big Is the Debt?
This debt is staggeringly large in actual fact. If we broaden the definition of TD to include the accumulated cost of maintaining and reworking outdated or suboptimal technology implementations, which are themselves a symptom of that debt, and poor software quality in general, which may be a cause of TD or a consequence of it, or both, the annual cost to organizations of all types and sizes is around $2.41 trillion according to The Consortium for Information & Software Quality™ (CISQ™). Its 2022 report states that “. . . finding and fixing bugs is the largest single expense component in a software development lifecycle.”1 Furthermore, the accumulated software technical debt is estimated to be $1.52 trillion in the US alone.
Industry analysis suggests that global TD has roughly doubled over the past decade, growing by about $6 trillion between 2012 and 2023.2 This in turn implies a cumulative TD of approximately $12 trillion total by 2023. This enormous “principal” of technical debt acts as a drag on innovation and efficiency, like barnacles and weeds on the bottom of a sailboat. Eventually, such a boat simply cannot sail fast in any direction and ends up being buffeted by winds and tides.
Organizations are paying a hefty “interest” on this debt. For example, many companies spend at least 40% of IT budgets just to maintain legacy systems and debt instead of adding new value.3 It is worth noting that a proportion of the TLT investment that we outlined above is currently being undertaken by organizations specifically to reduce the level of TD within their estates, with varying degrees of success. A Total Economic Forum study by Forrester showed that retiring old legacy systems could reduce combined hardware and operational running costs by 65%, so the rewards for getting it right can be significant.4
