How To Manage Technical Debt During Development?

What is Technical Debt?

Technical debt is a phenomenon that can be defined as the accumulation of time and effort spent on building software that is not as good as it could have been, or at least as good as it would have been if the software had been built by someone else. It’s a classic example of “time getting wasted,” It often happens because developers aren’t aware of all their options for improving their code before they build it.

Technical debt is any kind of cost incurred due to poor planning, bad design decisions, or other problems with the code itself. In short: It’s anything that might cause you problems later.

And this is where it gets interesting: Technical debt doesn’t just add up over time; it can be used to your advantage using the right management strategies!

Why identify Technical Debt?

Identifying technical debt is essential for several reasons. It helps developers understand which parts of their code are worth investing more time into optimizing. This can help them focus on those parts and avoid wasting time on optimizations that won’t yield big benefits.

Shouldn’t it be captured as defects and bugs?

In many cases, technical debt is not captured as defects or bugs because no tools or techniques are available that allow developers across organizations to communicate definitively about this concept with repeatable results.

While technical debt has long been negatively associated, it is not necessarily a result of personal flaws on the part of the technical team. This can be better understood with Martin Fowler’s Technical Debt Quadrants.

Here are a few steps that should effectively put you on the right track to managing technical debt:

1. Tracking

A good way to manage technical debt is to track it. And there are many ways we can do that. Tracking, planning, and estimation are the three main steps in the technical debt process. Usually, tracking will be the first step because we wouldn’t start work on all technical debts immediately. The reason for keeping everyone in a bucket is that the technical debt is identified in different ways or by different people who review code so that nothing can be missed. Also, it helps us with further activities such as updating efforts, prioritizing, and tracking status. Of course, there are many tools we can use for tracking, but just use the tools which are currently being used for your project. For example, if you are using Jira, create a card for the technical debt in the backlog/product log.

2. Planning

For planning purposes, decide what needs to be done in the current sprint or in the upcoming sprint. We can include our current sprint for the following reasons:

• Always give priority to security-related factors in the current sprint. This includes both security issues and performance issues.
• If the debt impacts business in production or affects other modules of your product (e.g., data integrity), it must be included in the current sprint.
• If the team has completed their sprint goal before time, investigate technical debt priorities impacting your sprint goal.
• If the technical debt is relevant to the current working module, it should not impact your sprint goal.
• If the debts are related to code refactoring, readability, and optimization, they can be planned in the upcoming sprint.

3. Estimation and resource availability

• Before assigning a task, discuss with each developer who worked on the module earlier and identify the impact before estimating hours/days.
• Review the developer’s current working task and pipeline and decide who can be picked for a new task.

4. Identify the impact on the current sprint goal

If a sprint is started with certain goals, but towards the end of the sprint, if we are facing any issues in delivering our deliverables due to new debts included which were not initially in the sprint plan, then you can decide which ones must be moved to next sprint according to its weightage.

Follow these steps to identify the impact:

• Step 1: The weightage of debt which was picked in the current sprint.
• Step 2: Compare debt weightage with items that are available in the current
• Step 3: Decide on the list of items that will not be delivered.
• Step 4: Bring out those items from the sprint and move them to the backlog.

5. Publish sprint deliverables in scrum meet (Product Owner, Scrum master, and Developers)

To make sure everyone in the same line, publish the plan with the following details:

• How many items are
• How many items are not
• Reason for goal changes.
• The action points for not delivered items.
• The benefits of goal changes and how they added value to the product.

Finally, confirm the goal changes with the product owner before starting work on it.

6. Let’s start working on debt.

While this is the last step in managing debts, it is the first step for developers to start working on the debts. Be diligent about keeping track of any tasks that are left incomplete—whether they’re big or small, they all contribute to the total amount of technical debt on your project.

Technical debt can lead to incomplete functionality and delayed releases, which can cause your team to lose credibility with customers and stakeholders.

So, what happens when you don’t take care of technical debt?

It gets bigger and more expensive to fix. In fact, when your technical debt becomes unmanageable, it can make things harder for everyone on your team—not just the developers who are working on each piece of code (or the users who are trying to use it).

Whatever tool(s) you choose, remember nothing beats face-to-face communication between developers and QA folks who understand the impact of each item—and make sure everyone knows who needs to do what. This also helps create better communication, empathy, and transparency between product and engineering teams and streamlines the process in the long term.

This blog is co-authored by Ashok Maruthamuthu, Technical Lead at Zuci Systems. Ashok comes with extensive experience handling technical debt on several projects.

Got questions? Write to us here.

Other interesting reads for you:

Spaghetti code originates from bad engineering leadership

Downside of not having a formal defect analysis feedback system