Technical debt management

When we develop software, we always try to create a clean technical solution with well-designed architecture and high quality on all application layers. But as we all know from experience, it is unrealistic to implement this positive intention completely because of the need to be agile and flexible to the business needs of the product and our clients. As a result, in specific stages of development, the produced software may have weaknesses and nonoptimal solutions caused by changes in the client’s business needs, schedule updates, or missed details in the original development plan.

These technical problems are usually called technical debt because we “owe this debt” to our application to make it clean from a technical perspective. (The Wall Street Journal recently published an article about this.) This metaphor was offered by Ward Cunningham, who developed the first wiki and coauthored the “Manifesto for Agile Software Development.”

Technical debt may look like various code-level or architecture-level problems:

• “Temporary” solutions for quick fixes 

• Outdated technology or library used for implementation

• Ineffective architectural decisions

• Deviation from technical standards and best practices

Why technical debt is a problem for the product

The implementation is completed and all necessary use cases are covered, so why should we worry about any inefficient solutions in the codebase? Because our products are changing and adapting to the real world! And every single iteration of this process demands codebase updates, which will become more and more complicated and time-consuming with the growing amount of technical debt.

In the article “Is High Quality Software Worth the Cost?,” Martin Fowler mentions the following dynamics connected with software quality: 

These dynamics show that the problems will start happening quickly (“in weeks, not months”) when quality is poor and we have a big technical debt.

Why technical debt comes up in projects

In another article, titled “Technical Debt Quadrant,” Martin Fowler provides a great typology of technical debt, which is called Martin Fowler’s technical debt quadrant. The quadrant explains which types of technical debt may exist and which decisions may cause it:

So, to keep the software quality high and the amount of technical debt predictable, we should act in a “prudent” way.

How to manage and measure technical debt in your project

Step 1 - Define technical standards

First of all, everyone involved in a project should agree on what will be considered technical debt for that particular project. Begin by defining a clear list of technical standards, which you can do by discussing the following questions:

• Do we use static code analysis? How? Which code style standards do we use?

• Do we create automated tests for every new feature? Which tests with what coverage do we need?

• Which architecture is chosen for our application? How are we going to support its consistency?

This list is not comprehensive; also include other basic questions related to your project. Once you have decided on the answers, a violation of these rules should be considered a technical debt.

Step 2 - Track your technical debt

Then, in every single case when you plan to violate one of the defined rules, or if you identify any other technical issues, you must immediately create a technical debt ticket (sometimes called a TD ticket) for your backlog. The ticket describes the problem in the codebase and generates specific risks, and it will take some time for resolution.

Step 3 - Measure the amount of your technical debt

The best way to measure everything is through metrics! So, create a metric that allows you to clearly understand how big your technical debt is, how quickly it grows, and how efficiently you deal with it. For this purpose, we can offer the following metric (consisting of 3 components), which covers all necessary aspects:

total number of TD tickets / number of newly created TD tickets during the last development iteration / number of closed TD tickets during the last iteration

Monitoring this metric will provide control over the quality of your software and represent a dynamic degradation/improvement.

Step 4 - Plan to fix your technical debt

You have to not only generate tickets for the backlog but also close them. To do so, you need to plan to fix these tickets stably and regularly, including a specific number of TD tickets for every iteration of the development process (except possibly in some crises when you have to focus on urgent, business-related tasks).

An alternative approach is to completely allocate one iteration for fixing TD tickets per several iterations. However, you will have to pause features development, and at the same time, it will be more complicated for the development team to focus on only tech improvements during the whole iteration. So, we don’t recommend this approach for the majority of projects.

How to communicate about technical debt efficiently

Usually, communication about the need to fix technical debt may become another challenging task because the client and product manager may not see immediate business value from these efforts. But you can help them to understand the risks and impact of not resolving technical debt.

To make further conversation smoother, communicate in advance about producing technical debt. If you have to speed up the development process because of business needs, thereby sacrificing technical quality, notify the relevant parties in advance. It would be even better if you could estimate the effort for fixing the issue and include a plan for a future release.

Then, if you need to communicate about the technical debt, start by providing the risks that this technical debt generates and the potential impact on development efficiency and operational expenses. The best option is to provide some examples of features and/or deliverables that will be released even faster after fixing the appropriate technical debt.

Following this recommendation, you can stay on the same page with your client or management about the need to support a reasonable amount of technical debt and hence high quality. 

At Lineate, we actively leverage the technical debt approach and always work with it in a controllable way, allowing us to develop high-quality software that is flexible for changes and growth.