How A Project Manager Can Recover From Technical Debt

Technical Debt is something we talk about a lot here at Duecode, and for a very good reason. After all, the amount of technical debt you have, and the way your team manages it, can easily make or break your project on its own!

As such, not only is it important to track the amount of debt you collect in your project over time, it is also critically important to learn the techniques to handle it properly, and with effective project management, recover from technical debt as quickly as possible.

This is exactly what we will be discussing in today’s article.

Introduction

Technical Debt is something project managers discuss a lot and in many different contexts. But what exactly is it?

In short, Technical Debt is an estimate of the compromise in code quality that a team makes in order to deliver updates on a tight schedule. When you have deadlines to meet, teams often find themselves in a position where taking the time to maintain code quality no longer becomes an option. As such, they fall into a debt where, instead of money, code quality is what they have to recover, which they previously compromised on while focusing on quick product delivery.

For the most part, technical debt is a natural part of any software engineering project. However, when it is not dealt with properly, it can accumulate over time and cause major problems. This is exactly why learning to recover from technical debt is such an important skill to learn in software project management.

Types Of Technical Debt

Not all technical debt is created the same. Technical Debt can roughly be classified into the following three types:

Deliberate / Intentional Debt

i.e., the debt that a software team deliberately takes on with proper planning and recovery tactics in mind

Accidental / Unintentional Debt

i.e., debt that the team accumulates without conscious intention, like using outdated design patterns, support-dropped libraries or tools, etc.

Debt from Entropy

Debt that is collected over time randomly. It is mostly caused due to one-tracked thinking within team members and general human error.

Knowing the type of technical debt you are dealing with at any given time is Step 0 for approaching the recovery process. Depending on the type accumulated, certain debt can be considerably harder to recover from than others.

For example, unintentional debt is harder to recover from than intentional debt, as they are often unexpected and unplanned. Figuring out a proper way to deal with them that is both cost and time-effective can take up valuable development time.

Similarly, finding and tackling debt from entropy/randomness can be equally tricky to deal with too.

Infographic. Types Of Technical Debt

Recovering From Technical Debt

Now that we have established the different types of debt, here are the steps to tackle them in an efficient way:

1. Use proper tools for debt estimation

Making use of proper tools is the first and most important step in recovering from technical debt. After all, things can go messy fast if you are relying on tools that give an inaccurate picture of the amount of debt you’re carrying.

A good code analysis tool is crucial for figuring out which parts of your codebase need refactoring and quality control. Popular choices include SonarQube, Duecode, Closure Compiler, Bliss, Check Style, etc.

Check out our detailed article here where we discuss how to measure code quality using Duecode.

2. Define Task Priorities

Based on the severity of different debt tasks, popular tools will use various metrics to define priorities of pending tasks. These metrics may include debt ratio, SQALE (Software Quality Assessment based on Lifecycle Expectations), and sophisticated debt levels.

Duecode primarily uses four main debt levels, which are provided in all generated code quality reports:

👉 Blocker (highest intensity)
👉 Critical
👉 Major
👉 Minor

Approaching debt recovery from the highest (blocker) level threats is usually the way to go, as these will result in the most notable performance optimizations. Subsequent levels (Critical, Major, and so on) should be tackled next after all highest level debt tasks have been dealt with.

3. Code Review and Repay Implementation

Now that a priority schedule has been mapped out for all debt tasks, the process of repaying technical debt can finally be started.

The first part of this stage will involve carrying out an in-depth review of the task at hand. Tools like Duecode can display low-level details using its various debt widgets, which helps greatly in pinpointing problem areas of the code. The second part will then include implementing the repay, i.e., refactoring the code in order to fix the code quality issue that was causing the technical debt.

This stage can usually be approached in three steps: Assessment, Communication, and Implementation. The problem area should first be assessed to find notable weak points, performance loopholes, etc., in the code. A plan for how long the debt might take the team to repay should be sketched out as well. Next, the plan should be communicated with concerned team members, where agile methods will be used to patch the problem as efficiently as possible.

QA analysis, automated testing, etc., follow after implementation. A technical debt report should be generated at the end so that the debt situation and progress can be tracked as well.

Conclusion

‘The sooner you start coding, the slower you finish’ - this old adage in software engineering holds true while recovering from Technical Debt. While repaying debt in your team’s software project, using proper approach, planning and strategies will go a long way in not only fixing the current problem at hand but making sure that future debts similar in nature to previous ones can be reduced.

And so, by iterating the above-mentioned steps, project managers can recover from technical debts in their engineering projects rapidly and efficiently.

Updated on the 2nd of November, 2021