How to measure technical debt (and reduce it)

Reading time: about 9 min

Topics:

IT and Engineering

Over time, the decisions you make today with your code start forming a legacy for the future. If that legacy costs you something later, in terms of additional time and resources to update the code, you can usually call that “technical debt.”

Technical debt can cause performance problems, a decline in quality, or a reduced customer experience. As such, your team should think carefully about how you take on technical debt and manage it.

Brief overview of technical debt

Essentially, technical debt builds if your development team chooses to take technical shortcuts—saving time and finishing the work faster, but potentially creating more problems down the line. Technical debt can also show up wherever technologies are in need of refactoring because they don’t scale appropriately anymore.

Over time, this technical debt accumulates and reduces the value that your organization receives from your technology. Eventually, you may have little choice but to replace your software or devote more resources to fixing it. This all adds up to a reduction in your technology’s return on investment (ROI).

Technical debt can mean prioritizing the speed of project completion or other short-term benefits over other benefits, such as:

Efficiency of the code: Inefficient code written now just means more work later when you have to rework or replace what your team has already finished.
Ease of maintenance: Coding decisions that are harder to maintain later can increase your technology costs.
Implementation of current technology: This involves choosing obsolescent technology because it saves time now, even if current technology is a better fit.

Ill-fitting code does not do your technology or your organization any favors.

Causes of technical debt

There are multiple potential causes of technical debt, and not all of them are necessarily the result of your team’s development decisions. These causes could include:

Development shortcuts: Saving time, not fully customizing code, sacrificing code performance, or making another tradeoff that has a negative impact
Obsolescent technology or approach: Technology choices that no longer fit your needs because your technology became obsolete or your organization outgrew your technology
Considered, planned decisions: The result of a deliberate decision that you made because it benefitted your organization

Technical debt may not benefit your organization in the long run, but it often appears because creating technical debt does deliver temporary benefits. Just like financial debt provides some benefits now that you pay for later, teams that allow technical debt to crop up in their code are often able to finish their work sooner, allowing them to move on quickly to the next project.

How to measure technical debt

Without appropriately measuring your existing technical debt, it’s a lot harder to determine how much of an impact technical debt is really having on your organization.

If you aren’t sure whether technical debt is causing problems at your organization, consider these warning signs:

Increased costs: As you notice technology costs rising, ask yourself whether technical debt accumulation could be the culprit. Technical resources, personnel, and infrastructure increases could all be tangible signs of a growing debt problem.
Decreased quality: A drop in quality and CX could be caused by code that’s no longer functioning as well as it used to.
Time-to-value grows: When it takes longer to deliver the same level of value to your customers, technical debt is a possible cause. Your customers could be waiting longer for their product to work or your service could be slowing down to a crawl.
Value delivery speed drops: Your flow velocity, or your technology’s ability to accomplish work within a certain time frame, is a vital measure of whether you’re improving upon your value delivery speed.

To measure your technical debt, start by looking at where your work is right now:

Security risks: Does your technology have security weaknesses? What coding decisions may reduce the overall security of your product? Does your code do enough upfront to manage future security risks?
Existing defects: What do you know about defects in your code? Are any existing defects left unmanaged or uncorrected?
Structure and infrastructure debt: What system relationships may be contributing to technical debt? Is outdated infrastructure potentially to blame? Does your code fit with your infrastructure?
Discontinuity and breakdowns: Are there notable downtime incidents you can refer back to for insight into your technical debt? Are there any systems that are currently nonfunctional? Can you foresee the possibility of downtime, either as a consequence of coding decisions or due to technology that no longer meets your needs?
Application debt: Looking at your application at a high-level, do you notice other potential issues or risk areas? Consider the functional performance of your application and whether the application is aligned with your business needs.

Using your technical debt ratio

By calculating your technical debt ratio, you can determine what fixing or replacing the system would cost. From there, you can compare your options.

Here are a few tools you can use to find your technical debt ratio (TDR):

SQUORE: A web-based technical debt management solution
SonarQube: A free, open-source code quality management system
Kiuwan: A SaaS option with different plans to track more than 60 technical debt metrics

After taking the time to understand your technical debt, you can craft a plan to manage it.

How to manage your technical debt

While deciding how you’ll manage your tech debt, you may want to consider what resources and time your organization will need to address it. This is all dependent on the types of debt you’re working with, how long paying down your technical debt will take you, and what technical debt you want to focus on. Managing your technical debt will cost you, but you should see that as an investment in your organization.

To start managing your technical debt:

Finish measuring and understanding your debt: Run through any measurements and evaluation you need to understand the scope of your technical debt. You want to do this before undertaking payback.
Create your payback “budget”: Determine how much time you’ll set aside to manage your debt. 20% of development time is a fairly typical choice. It leaves a majority of your team’s time for other development projects but still ensures that you’re managing your technical debt effectively.
Pay back the right debt first: Just like high-interest credit cards, you may have technical debt that you want to tackle before you address anything else. This is the debt that provides you with the best ROI if you solve it right away, bringing you quick improvements in key metrics and areas such as performance, quality, or flow time.
Plan a payback timeline: As you decide how quickly you’ll repay your tech debt, consider your business needs and how making payments to your technical debt will have an impact on your customers, your operations, and your development goals. If you repay too quickly, the impact may be too costly in the short term, but repayment that’s too slow risks missing out on the benefits of reducing your debt.

With your payback plan in place, it’s time to start paying off your technical debt.

How to pay down your technical debt

Keeping technical debt at manageable levels requires some advance planning and ongoing action to mitigate potential risks while still maximizing the benefits of any technical debt you do decide to carry. Believe it or not, there is such a thing as “good” technical debt that’s worth carrying—but any amount of technical debt should also mean you have a plan to pay it all back when you need to.

Take these steps to pay down your debt:

Don’t look for a scapegoat or someone to blame. Ultimately, technical debt is a reality for anyone developing software. Avoid the temptation to blame previous managers or developers. Blame is counterproductive and does little to solve the problems you face today.
Quantify your technical debt in terms of time and money. Using your measurements, look at how this debt impacts your business so you can determine what the business impact will be.
Be intentional about managing debt. Avoid taking on more technical debt without knowing what that debt really means. You should also be intentional as you pay it off—paying off technical debt for its own sake isn’t always a smart idea. Sometimes keeping the technical debt saves resources you need now, and the benefits might outweigh the disadvantages.
Consistently stick to your technical debt plan. Keep up with code maintenance, continue managing your debt, and regularly reevaluate where your technical debt is at.
Account for your technical debt properly. Think of your debt as a financial debt listed as a liability on a balance sheet. Stay honest about what technical debt you are carrying, adding, or subtracting. It’s easy to lose track of technical debt you aren’t accounting for properly.
Have a little faith in your technical team. You need their insight to determine what code needs to be refactored and maintained. Consider what they have to say carefully.
Remember that managing technical debt is hard. Technical debt can carry with it a lot of tradeoffs and can offer benefits as well. All in all, there is no one right decision or approach to managing technical debt.

Visualize your technical debt

You can use visualization platforms to help you picture your technical debt and craft a management plan. With the ability to see your technical debt, you can start determining how you’ll proactively address it as a team and as an organization.

Technical debt tree: Taking your known technical debt into account, you can draw a tree to map out which projects can be addressed more easily and readily and which ones will take more time and resources to resolve. You would then place sticky notes on the tree to represent each form of technical debt.
Technical debt matrix: Forming a matrix with an x- and y-axis, you can place sticky notes along each axis to represent differences in delivered value and difficulty level associated with addressing the debt.

Lucidchart can help you understand where your technical debt stands and which projects should be resolved next based on real-time needs and technical debt loads.

Manage your technical debt

Your team can make proactive technical debt decisions using the right software and approaches for examining your technical debt and creating a management plan. Know your technical debt metrics and be prepared to measure your technical debt as you work.

With the right strategy, technical debt can become a valuable tool rather than a hindrance to your organization’s goals.

Lucidchart is the visual workspace where technical professionals can gain visibility into existing tech, plan for the future, and communicate clearly with stakeholders.

Learn more

About Lucidchart

Lucidchart, a cloud-based intelligent diagramming application, is a core component of Lucid Software's Visual Collaboration Suite. This intuitive, cloud-based solution empowers teams to collaborate in real-time to build flowcharts, mockups, UML diagrams, customer journey maps, and more. Lucidchart propels teams forward to build the future faster. Lucid is proud to serve top businesses around the world, including customers such as Google, GE, and NBC Universal, and 99% of the Fortune 500. Lucid partners with industry leaders, including Google, Atlassian, and Microsoft. Since its founding, Lucid has received numerous awards for its products, business, and workplace culture. For more information, visit lucidchart.com.

Let’s talk about technical debt in Agile
Technical debt is similar to financial debt in that you’re making a tradeoff for something now that will need to be paid back later. In this article, we’ll explore technical debt in Agile and ways to reduce it.
Reduce technical debt with diagrams
Diagrams will be your best friend as you tackle the technical debt you've accrued. Use Lucidchart to simplify your process and break down tasks.
How to create and manage technical documentation faster
Creating technical documentation doesn’t have to feel like a chore. These best practices can dramatically speed up the process and keep essential information within your team.