“Not all debt is bad debt” is a concept typically reserved for financial experts and budgeting gurus. There are, after all, good types of debt: mortgage loans, well-researched business loans, and even credit card debt that is paid off every month without ever charging interest. The issue is bad debt: high-interest car loans, personal loans, and long-standing credit card debt on a high-interest card. The trouble starts not when there’s debt, but when there’s bad debt—or debt that gets out of hand.
These underlying principles of personal debt management readily transfer over to technical management. The answer to the question, ‘Is all technical debt bad?’ is also no—there are both good and bad types—but it’s crucial for today’s businesses to recognize which is which and how to mitigate as much bad technical debt as possible. By knowing what bad technical debt looks like, how to prioritize different types of bad debt, and the right processes for resolving technical debt over time, companies can more safely leverage technical debt in the future.
The Key Difference Between Good and Bad Technical Debt: Intentionality
Very few companies can remain competitive by refusing to take on any technical debt at all. For example, many companies start to incur debt by choosing an expedient solution that allows them to meet a business-critical deadline. They might push out a new feature now and send patches or updates later.
This is much the same way a business might take out a business loan to cover inventory before a peak sales season; you’re taking on controlled risk and liability to secure the immediate resources necessary to grow. Your team can leverage good technical debt to grow your business, allocate resources to the most important projects, and ensure customer demands are satisfied.
Related: Taking Control of Technical Debt: How Continuous Refactoring Transforms Applications
By refusing to have any technical debt, project costs and timelines can quickly balloon. It can also be an impossible standard to meet, leaving your organization unable to even acknowledge the technical debt that does occur. So it’s better to anticipate it, manage it, and even leverage it.
This leads to the core difference between good and bad technical debt. In personal finance terms, the interest rate and the purpose of a loan determine whether it’s good or bad. But in software, it’s much more about intentionality.
- Did your team sit down, discuss the risks of the debt, decide it was worth it, and create a plan to address it in the future? If so, it’s good technical debt.
- Did your team take a shortcut without really considering the implications? This is bad technical debt, with unknown ripple effects and no plan in place to resolve it.
When you intentionally choose to take on debt and you understand its primary implications, it’s a measured response to circumstances that can strengthen, rather than jeopardize, your technology.
How All Technical Debt Can Go Bad Over Time
There is one complication here: even good technical debt goes bad. Just like good business loans become a bad liability when they stack too high or you don’t make timely payments, previously good tech debt transforms into a very risky liability. Here’s how:
- The project managers that originally accounted for it lose sight of it or leave the company, which means the debt no longer has an active plan to address it.
- The risks of technical debt have grown over time. Naturally, older code experiences drift, will start to have out-of-date components, and will develop bugs. This compounds the effects of even good debt until it’s a much bigger—and a much less well-perceived—problem.
- Entrenched problems make the cost of resolving the technical debt higher and higher. For example, if your Dev team sticks with a legacy platform for a new product release during peak season, they’re incurring good tech debt because they’ve considered the cost of eventually refactoring the original legacy work and the new product release. But if that same decision-making process happens again and again, the cost of refactoring grows bigger and bigger.
Even good technical debt is debt, and virtually all technical debt turns bad eventually unless you manage it carefully. Even worse, there may be technical debt your organization doesn’t even know about. A fundamental process for resolving technical debt is constantly monitoring your systems to catch technical debt that may have slipped through the cracks so you know what technical debt lingers unanswered.
One form of potentially invisible technical debt that can do the most damage behind the scenes is architectural technical debt. This challenge can creep up on any organization, especially if you have long standing programs.
Some forms of architectural debt are architectural drift—which happens as code departs further and further away from the original vision until it borders on becoming unrecognizable—high complexity that can make identifying and resolving technical debt much harder, dead code, dependence on third-party libraries and legacy systems, and so on. Architectural technical debt can be so insidious that it’s important to have specific projects and processes created just for countering it.
Why You Need to Care About Technical Debt
Technical debt of all forms has real business implications. Externally, it can lead to performance issues, customer frustration, product failures, and opportunity costs that let your competitors surge ahead. Internally, it can be frustrating for software developers, cause projects to have increasingly long timelines, and result in friction between strategy, product, and IT teams. These potential harms come with both good and bad debt, but there are also unique consequences of both categories.
How Bad Debt Hurts Your Company
- It’s often invisible. While companies can use a variety of static tools to monitor some source code issues, these often don’t account for architectural technical debt.
- Fishing out and resolving technical debt is very complex and takes a lot of time.
How Good Debt Hurts Your Company
- The programs are still changing from your original architectural plans through the workarounds and shortcuts.
- The debt needs to be accounted for in the future, impacting future productivity.
- Eventually, it may reach a critical mass, becoming bad debt, leading to unstable software, unhappy teams, and a poor business reputation.
Ultimately, both forms of debt always have a negative tinge; they add up with liabilities and capital on the opposite side of your corporate balance sheet from positive assets.
Two Important Steps for Handling Technical Debt
Because technical debt is virtually unavoidable, companies need to make efforts to (i) make sure as much of it as possible is good debt and (ii) resolve it as quickly and efficiently as possible. There are two priorities that must be addressed:
Priority #1: Recognize the Technical Debt
This is the first step your organization needs to take to make technical debt more manageable. On current projects, start recognizing the technical debt incurred by different actions and make it part of the project documentation. As you standardize this process and add it to how you manage projects in the future, it will become easier, and you’ll have clearer records of technical debt to-dos.
Related: Empowering Your Software Evolution: Unleashing the Potential of Continuous Modernization
It’s just as important, if much more difficult, to go through and identify technical debt generated in the past. Modern AI-powered software can comb through the source code and architecture to make in-roads in identifying it. Over time, the software will become more adept at uncovering, identifying, and reporting technical debt, operating efficiently behind the scenes until it needs action from a human developer.
Priority #2: Create a System for Managing and Resolving Technical Debt
As your processes for identifying technical debt are whirring away, it’s time to start methodically addressing it. Just like all aspects of project management, it’s important to create a system that makes action predictable, consistent, and easy to continue over time. Build out your process with these four components:
#1: Create a Priority Schema
Not all technical debt can be addressed at once—nor should it. Work with key stakeholders to decide what types of debt should be the priority to solve in different situations. For example, you can adopt the “snowball method” of addressing personal finance debt: start with the lowest-impact but easiest-to-resolve debt, like source code bugs.
Alternatively, you can adopt the “snow avalanche method” by tackling the costliest debt first, knowing that the work will be hard but the positive effects will be magnified. You can also prioritize by focusing on architecture simplification, choosing to shore up core product lines first, or other hierarchies.
#2: Choose the Right Resources to Track It
Choose the right stack of tools that can help your company track technical debt. Ideally, your tools will be able to track both source code and architectural technical debt, whether it’s outright bugs, incompatibility that grows over time, or architectural drift as the applications start to move too far away from the original design.
#3: Create Technical Debt Reduction Projects
Once you have a growing list of technical debt, create projects where addressing it is the primary focus. This is different from other forms of projects, in which addressing technical debt is a secondary priority or teams care only about reducing the total amount of new debt they create along the way. These projects focus solely on resolving technical debt, and your leadership team needs to make it their mission to prioritize them, even in the face of tempting new product feature projects.
#4: Make It Part of Your Standard Project Processes
Alongside the direct technical debt projects, make some technical debt recognition and resolution tasks a standard part of all agile projects. You can build elements of technical debt resolution into the software development lifecycle (SDLC) by ensuring new developments do their part to address technical debt. This is much better than ignoring the problem altogether or only addressing technical debt during technical debt projects. By regularly fortifying, updating, and simplifying how new code relates to the whole, you can reduce technical debt as a standard part of doing business.
By managing it on a regular basis, keeping documentation current, and flagging problematic debt that needs to be directly addressed, you can avoid having both good and bad tech debt stack up.
Incurring Debt Is Part of Business—Resolving It Should Be, Too
Technical debt is a constant. But that doesn’t mean it can be ignored—in fact, ignoring it transforms every type of technical debt into an unaudited risk and looming liability. Instead, your company needs to develop a multi-pronged strategy for addressing it. This should include recognizing it, monitoring it, documenting it, and—ultimately—refactoring or rearchitecting your code to eliminate it.
At vFunction, our suite of technical debt recognition and resolution tools can help with all of these elements. Reach out today to see how automating the identification and problem-solving aspects of technical debt management can help.
