DEV Community

Cover image for Tools to Track and Manage Technical Debt
Alex Omeyer for Stepsize

Posted on • Originally published at stepsize.com

Tools to Track and Manage Technical Debt

If you are looking for a tool to start managing technical debt this article will help you make the right decision. We will look at the tools to track small, medium, and large pieces of debt and the process to reduce technical debt.

Originally published at https://www.stepsize.com/blog/tools-to-track-and-manage-technical-debt

Why tracking technical debt is important?

In the previous article, we looked at why managing technical debt is crucial. Technical debt happens when a development team speeds up the delivery of a project or functionality that will require refactoring later on. Technical debt causes delays in releasing new features, hinders innovation, and decreases the engineering team’s job satisfaction. Companies that manage their technical debt effectively ship 50% faster, have happier teams, and save millions of $ in revenue.

By simply putting the right process for managing technical debt in place, businesses can boost their productivity and make sure their velocity will not drop down.

Alt Text

How do companies manage technical debt?

The study from 2018 surveyed 226 participants from 15 large organizations. Only 7% of them were tracking technical debt using tools and documentation, and only 3,5% - confirmed that all members of the organization participate in tracking technical debt.‍

Alt Text

Tracking Individually: "I track technical debt in our system using tools, documentation, etc."
‍Tracking Team: “All team members participate in tracking Technical Debt in our system.”

According to Stripe, maintenance of legacy systems and technical debt are considered the number one reason for hindering developer productivity. Yet only a small percentage of companies have a process for managing technical debt.

Analyzing the study and 200+ interviews we’ve conducted at Stepsize as part of the customer development work, we've identified 6 types of tools that help manage technical debt:

Documentation
Many teams use wiki pages, Trello boards, or Microsoft Excel to document technical debt issues. Such documentation is helpful to bring visibility into technical debt across the teams.

Project Management tools
Backlogs in Project Management tools are the most used tool among all organisations, Jira, Hansoft, and Excel, in particular.

Dedicating a backlog to tech debt issues is a way to catalog and document the debt in your codebase. Unfortunately, while better than nothing, such backlogs can be hard to maintain as engineers will accumulate a mountain of refactoring tickets until they stop tracking this data because they notice these are often lost in the noise or simply never prioritised.

Static analyser
Tools such as SonarQube, SonarGraph, Klockwork are used to analyse source code in search of technical debt.These tools use quantitative data to help developers identify hotspots in the codebase likely to have technical debt. One of their limitations is that they won't help you identify medium to large pieces of debt that span multiple parts of your codebase, and won't provide you with the context necessary for you to truly understand each piece of debt and how to prioritise and ultimately tackle it.

Linter
Linters are a type of static analysis tool used to flag programming errors, bugs, stylistic errors, and suspicious constructs which sometimes includes technical debt.

These tools, especially when paired with your deployment pipeline, help limit cruft by allowing you to enforce some coding standards across the whole engineering team. Among other things, maintaining these standards will help improve the readability of your code.

Test coverage
Some of the respondents measure test coverage and consider low test coverage or outdated tests as a form of tech debt.

Technical debt management
This is a new category of tools especially designed to fill the gaps left unaddressed by the other tools above. SaaS products like Stepsize allow engineers to track tech debt of any size directly from their workflow. This data allows teams to gain visibility into their tech debt, understand its impact on the business, and get the necessary buy-in for appropriate resources to be allocated to addressing important tech debt.

Let’s now look at how you can use these tools to reduce your technical debt depending on the size of your debt.

Small, medium, and large technical debt

To start managing your technical debt, you first need to decide whether you are dealing with the small, medium, or large pieces of debt - and work separately with each.

Small pieces of debt: the type of tech debt that can be addressed as soon as the engineer spots it in the code and it’s within the scope of the ticket they're working on.

Medium pieces of debt: the type of debt that can be addressed within a sprint. It should go through the same sprint planning process as any feature work and be considered just as rigorously.

Large pieces of debt: the tech debt that cannot be addressed immediately or even in one sprint. The best companies we've interviewed have quarterly technical planning sessions in which all engineering leaders participate.

Alt Text

The process is the key

Successfully managing medium and large pieces of debt is all about adopting the right processes. Simply using the tools without adopting the right process will not move the needle.

At Stepsize, we've spent countless hours refining what we learned from the hundreds of engineers we speak to into the perfect process to manage tech debt, and delivered the ideal product to accompany it.

At a high level, this process is very simple, and our SaaS product will accompany you every step of the way:

Track: Report tech debt impact from your workflow.
Prioritise: Use insights to identify high value refactoring work.
Fix: Address tech debt blocking your roadmap.
Measure: Create tech debt KPIs and reports for your progress.
The process differs for small, medium, and large debt. For example, you don’t need to track small pieces of debt - just fix it. Prioritisation comes in handy for medium debt - you can discuss it at the sprint planning meeting, fix it during the sprint, and measure progress weekly.

Large debt would be identified from collections of daily reports and proposals, be prioritised on a monthly or quarterly basis, and fixed and measured at this same cadence.

How does Stepsize work compared to other tools?

Alt Text

If your database is old and many engineers have been working on it for years, chances are high that automatic code analysis tools will show you a lot of technical debt.

However, not all technical debt needs to be addressed right now. You can't boil the ocean anyway! For example, you may find parts of your codebase are riddled with technical debt, but that it's not materially impacting the business by causing bugs and that you won't be modifying this code in the near future. In that case, you should prioritise the debt directly in the way of the features you plan on shipping next, and leave the rest alone.

So what will Stepszie help me with?

Stepsize you will make better strategic decisions by bringing visibility and awareness to the technical issues. Your team will be able to:

  • Improve how you track technical debt
  • Communicate with non-technical stakeholders
  • Make the case for technical initiatives

Key takeaways

If you're a small team of engineers working on a small and young codebase, you can start small. Apply the boy/girl-scout rule, adopt appropriate code quality and test coverage tools, and regularly clear the debt in the way of the features on your product roadmap.

However, if you're a larger organization suffering from the consequences of technical debt despite having adopted these other tools and processes, Stepsize is the right choice for you. Get started today at stepsize.com

Top comments (2)

Collapse
 
arvindpdmn profile image
Arvind Padmanabhan

Wonderful article. I like the table comparing small/medium/large debts. Good to know that Stepsize is one more useful tool. I will add it to Devopedia's article: devopedia.org/tools-to-manage-tech...

Collapse
 
alexomeyer profile image
Alex Omeyer

Thanks a lot, Arvind!