What is Technical Debt?

Understanding what technical debt is and how it is created.

The term “technical debt” was initially coined by programmer Ward Cunningham in 1992 to illustrate that, while a software development organization may benefit from taking shortcuts to deliver application code, the “interest” from the technical debt, much like financial debt, will be far more in the long run than the costs of refactoring code to be more sustainable over the long-term.

A well known example of technical debt and its eventual cost:

Consider the Y2K software problem, a stark example of technical debt's impact. In the early days of computing, memory was costly, leading to a decision to represent years with only two digits. While this choice seemed expedient at the time, it resulted in substantial technical debt. As the year 2000 approached, the inadequacy of this decision became evident, requiring extensive remediation efforts to prevent system failures. What appeared as a minor shortcut initially transformed into a critical issue with tangible real-world consequences, demanding significant investments for resolution. This serves as a poignant reminder of how seemingly minor decisions can accumulate into substantial technical debt over time.

To put this in the context of remediation costs, consider this:

“In November of 1999, the U.S. Department of Commerce put the total cost of Y2K remediation at $100 billion. By 2006, the number had climbed. IDC published a report that year calculating that the preparation and New Year’s Eve costs in the U.S. totaled $134 billion, with an additional $13 billion spent fixing minor problems in 2000 and 2001, according to analyst John Gantz. Worldwide, organizations were estimated to have spent $308 billion before the millennium on remediation efforts.”
— www.reuters.com

In 2007 technical debt was characterized as intentional/deliberate and unintentional/inadvertent debt. Today the definition has expanded greatly to no fewer than thirteen types which include notions such as architecture debt, defect debt, people debt and test debt. The chart below illustrates at a basic level where debt comes from as part of the decision making process. Each quadrant represents a ratio or weighting of the dividers in the chart. You can see that when decisions are made in the bottom left quadrant that the technical debt incurred is far more damaging then debt that is incurred when decisions are made in the top right quadrant. Later in this series we will explore some of these points in the context of an engineering data management system.

In software development, accruing technical debt is often viewed as a risky practice, but there are situations where it can be a justifiable trade-off. Similar to financial debt, when managed effectively, technical debt can yield benefits.

For example, accepting technical debt might be warranted if it enables faster software deployment, giving a company a competitive edge by entering the market ahead of competitors. Early market penetration can lead to significant revenue, which can then be used to expand the development team and address the incurred debt. However, it's crucial to carefully assess the consequences of taking on technical debt before making a decision. Thoroughly quantifying the implications ensures informed decision-making and mitigates potential risks..

In the context of engineering data management, technical debt should be avoided at every turn. Technical debt in data management is very hard to reverse and pay down once it has accrued. The reason is there all types of engineering data technical debt getting generated by a myriad of engineering tools; CAD systems, PDM/PLM systems, analysis tools, etc. Keeping all the data these tools create in sync and providing maintainability at reasonable cost is at the very least a highly complex effort. It is therefore an imperative to identify and mitigate the creation of technical debt in engineering systems to provide a foundation that can scale and provide for the growth companies require.