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.
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.
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:
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.
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.
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.
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.
Some of the respondents measure test coverage and consider low test coverage or outdated tests as a form of tech debt.
This is a new category of tools especially designed to fill the gaps left unaddressed by the other tools above. 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. The Stepsize VSCode and JetBrains extensions help devs bookmark code, create issues directly from the editor, and collaborate on maintenance work.
Let’s now look at how you can use these tools to reduce your technical debt depending on the size of your 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.
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:
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.
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.
Stepsize is an editor-first issue tracker for a healthy codebase that helps Engineers: