If you have worked in technology transformation for any length of time, you have probably heard the term technical debt. Programmer Ward Cunningham, one of the co-authors of the Agile Manifesto and creator of the Wiki, coined the term in a 1992 article. He articulated that while the enterprise may save money in the short term by shipping early versions of code or software, the long-run “interest” from the tech debt, as with monetary debt, will accumulate, making the initial problem increasingly costly to fix with time.
However, as the term has grown in popularity it has morphed to encompass a host of issues currently facing technology transformation efforts. Technical debt (also known as code debt) has grown from simply the implied cost of additional rework caused by releasing a limited solution, to a catch-all term in the tech transformation space. It is used to describe everything from bug fixes to outdated legacy code and even to imply that a company’s technical infrastructure is behind or needs major revamping.
Technical debt is something both business and technical managers must handle. When a business plans to move into a new space, technical debt will need to be taken on to move fast. Products must continuously evolve to meet shifting demands. The decision to take on tech debt is a recognition of the trade-off between agility and perfection. Even well-designed software can accrue tech debt when the needs of the organization change.
Tech debt can sound bad, but when it is employed effectively and managed appropriately, it can be embraced as a tool for growth rather than a crippling burden an organization must bear
# What Technical Debt Is Not
To better address technical debt in the context of your business, it is important to first separate it from other potential strategic or operational issues. Below are a few activities that stretch the definition of tech debt and cannot be solved with a purely technical approach:
- A wrong feature or deferred functionality (That is a design issue)
- Unreasonable deadlines that force developers to make quick releases (That is a resource management problem)
- Lack of product ownership or customer feedback (That is a management problem)
- Bad or unreadable code (That is bad code management.)
- A lack of documentation underpinning your processes, projects, or code (That is bad document/ process management)
The last two points are especially important. Bad documentation or non-annotated code are often mischaracterized as tech debt when they are issues related to management and process. A key element of technical debt decisions should be rational choices based on project constraints.
# Good vs. Bad Technical Debt
Technical debt is a cost of doing business. All technology eventually needs to be replaced or rebuilt to react to changing needs and to seize new opportunities. But just like financial debt, there are good and bad kinds of technical debt.
What is Good Tech Debt?
Good debt is leveraged to create more opportunities in the future. In financial terms, good debt would be things like education, property, or financial vehicles that will grow over time and generate more value than the initial debt.
In technical terms, good technical debt could be a decision to release an MVP with the goal of understanding a customer base. These are decisions that will accrue tech debt in the short term but provide value to the company and the possibility of greater future revenue.
What is Bad Tech Debt?
Bad debt is money used on assets that are not valuable or depreciate rapidly over time. In financial terms, bad debt would be like buying a house built in a known floodplain or purchasing a car that turns out to be a lemon and breaks down immediately.
Similarly, bad tech debt is continuing to invest in products that do not align with business purposes and yield increasingly minimal returns. Examples would be software that is increasingly outdated or costly to maintain, such as solutions that are still coded in an outdated coding language such as COBOL or C.
# 5 Ways To Examine Technical Debt
Technical debt will undoubtedly enter the picture on any project. Whether to ship code early and accrue debt is only known to be a good or bad investment in hindsight. However, there are ways you can examine technical debt to develop a clearer picture of a company’s approach. Understanding the debt you already have, how it is currently being managed, and how it impacts the movements of your business are essential for growth and outperforming competitors and an important first step in successfully integrating it into your overall tech strategy.
1. Intentional vs. Accidental
When it comes to determining the type of tech debt, begin with a simple but very telling question: are you aware that you have debt? Are both your development and business teams aware of the trade-offs they are making to ship code or patch a system?
 Intentional |  Accidental |
| Intentional debt is the product of deliberate consideration. When organizations intentionally leave room for improvement in their code for the sake of reducing time-to-market, it can be classified as good debt. An example of this would be a startup shipping code with known bugs in it, with the express intention of experimenting with a new market segment to see which features will gain the most traction. | Accidental debt occurs well—accidentally. This can happen when the quality of the code or IT needs improvement over time due to inherited tech from a former colleague or third-party. An example of accidental technical debt would be Bit Rot or software entropy, which occurs through small, incremental changes, by many people, over time. This causes the devolution of software into a complicated mess that no one understands and can even break the system entirely when pushed beyond its original operational parameters. |
2. Accumulating Debt: Low vs. High Technical Gearing
In finance, gearing is the ratio of a company’s debt relative to its equity. Applied to tech debt, technical gearing is the ratio of the technical debt of a company to the benefits of the process.
Low Technical Gearing | High Technical Gearing |
| Low technical gearing means that the company’s income is higher than the cost to remediate the technical debt. This means that most of an engineer’s time is spent not on servicing the debt through tasks like bug-fixing, but instead through the roll-out of new features, which allows the business to be more agile and responsive to changes. | If a company has high technical gearing, the technical debt is large enough that most of the company’s income is spent servicing the debt. This means the engineering team is spending most of its time patching the system (or servicing the debt) rather than innovating. An example of this would be a legacy system that has been made a lynchpin of a company’s product lifecycle being patched continuously when it is no longer fit for purpose. |
3. Prudent vs. Reckless
With any kind of debt, you want to be sure you are taking it on with thoughtful consideration. Just like you wouldn’t, or shouldn’t, recklessly max out your credit card without a reasonable payment plan in place—you shouldn’t recklessly accrue technical debt without a plan for paying it down.
Prudent | Reckless |
| A prudent team understands the decisions about the debt they are making. While they cannot predict the future (don’t we all wish we could predict with certainty the success of our investments?), they understand they are borrowing against future returns and have a plan in place to manage time effectively. An example of this kind of prudent thinking would be understanding the scale limitations of a particular feature and having a plan in place to add capacity or replace it should a user capacity threshold be met. | A reckless team treats technical debt like Maverick from Top Gun—writing checks their body (or in this case their tech) can’t cash. They do not understand the impact of their decisions or have a plan to pay back the technical debt they’ve accrued. An example of reckless decision-making would be to assert a deadline over functionality and prioritize product release over understanding limitations. |
4. Ramifications: Linear vs. Exponential
All debt grows over time, but not all debt grows at the same rate. While some debts grow steadily and predictably, other debts can grow massively and affect an organization’s ability to conduct business.
Linear | Exponential |
| Debt that grows in a predictable, linear way and will not completely derail the company if it needs to be taken offline to fix, is good, safe debt. This type of debt tends to be smaller issues that limit elements of an organization’s functionality or product rather than the entire organization. An example of linear technical debt would be the lack of automated testing for software quality. | Exponential technical debt can cause cascading failure to multiple parts of the organization if it ever hits a break state. These technical debts are related to fundamental elements of a company’s business model, and failure to address them impacts not just a company’s tech infrastructure but the reputation and ability of that company to do business. An example of this kind of exponential debt would be if a data company had a limit on the amount or throughput of data it could ingest. If an organization is carrying more than one instance of exponential technical debt, it is at high risk of default. |
5. Mitigating Debt: Write-Off vs. Sunk Cost
Sometimes, despite best intentions, a technical solution is simply not fit for purpose. Whether it be the collapse of a vendor, the lack of scalability in a solution set, or simply a bad underlying assumption in your platform, some technical debts are simply not worth servicing. This is especially prevalent in companies with a “fail fast” mentality. When this occurs, companies are left with two choices: keep investing or write the debt off.
Write-Off | Sunk Cost |
| Acknowledgment that a technical debt simply has gone bad and needs to be written off or replaced is an indicator of good technical debt decision-making. While debt that must be written off is not good debt, if the decision is made decisively and the technical debt is relatively contained (i.e., low leverage and linear), the loss can potentially be absorbed by performance in other business areas and can pave the way for other more holistic solutions. | Doubling down on false assumptions and chasing good money after bad debt is a marker of bad decision-making. It can lead to your technical environment failing entirely to meet the needs of the business. To further use financial metaphors—you don’t remodel the kitchen of a house that is underwater, so why would you keep pouring money into a technical solution that has proven not to work? |
# Summary
While the term technical debt has been around for almost three decades, it is still being misrepresented and, even worse, not included in many organizations’ overall tech strategy. Code and software will constantly need updating and revisiting, therefore tech debt management must be an important part of your tech strategy.
Just like a sound financial investment, technical debt that is taken on thoughtfully—and with a repayment plan in mind—can be a valuable tool for an organization to achieve accelerated growth.
Related Content: 5 Ways To Help Agile Teams Move Faster
Propeller helps complex companies—at the intersection of People, Process, and Technology—redefine business goals and solution strategies. We help optimize technology product delivery, organize teams to deliver exceptional value, and effectively identify and mitigate corporate risk. Learn more about our Tech Transformation Practice Area.
