How to manage Technical Debt
Tags: programming, bestpractice, techdebt, management
Published: 2018-11-14 06:04:19

---
title: How to manage Technical Debt
published: true
description: How to live with technical debt and how to fight with it. I want to share how I prefer to manage technical debt and what it gives to me in a result.
tags: [programming,bestpractice,techdebt,management]
cover_image: https://thepracticaldev.s3.amazonaws.com/i/zp9672ipw6b2ice6010b.png
---

Originally posted on my blog [apastuhov.com](http://apastuhov.com).

---

Today more people think about technical debt than 5 years ago. Because every project has a debt, but not everyone drives it. And even if they drive - they will just keep a snowball in most cases.

I want to share how I prefer to manage technical debt and what it gives to me in a result.

## Definition and the problem

What Wikipedia tells us:

> Technical debt (also known as design debt or code debt) is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy solution now instead of using a better approach that would take longer.

> If technical debt is not repaid, it can accumulate ‘interest’, making it harder to implement changes later on. Unaddressed technical debt increases software entropy.

In easy words, technical debt means a list of invalid solutions, which you or your team made by mistake. Do not forget - everyone can be wrong. So if you do not manage your debt - you will get the next list of problems.

- Demotivated team
- Have no ability to control project risks
- Increased software entropy
- Everyone would like to rewrite the whole project from scratch

<img title="Debt is normal be weird" srcset="https://thepracticaldev.s3.amazonaws.com/i/oprsu6uy9s9q2k8j0fwg.png 100w" sizes="50px" src="https://thepracticaldev.s3.amazonaws.com/i/oprsu6uy9s9q2k8j0fwg.png"/>

## Causes

List of causes can be very big, but I defined the most popular from my point of view.

- Requirements are still being defined during development
- Development starts before any design takes place
- Business pressure
- Lack of process or knowledge
- Last minute specification changes
- Poor technological leadership
- Lack of collaboration
- Outdated technologies
- Bad development practices

You noted that most of those causes related to a business or a client. And this is true - in most cases, technical debt is filled-up in collaboration with your manager. You should hear the next phrase.

> Do it now because we *really* need.

And then you come to some compromise via increasing of your technical debt.

Disclaimer: At the end of the article you will find a link to the full list of root causes.

## Technical debt and PoC

If you work on a Proof of Concept, do not worry about technical debt. Because someone will replace PoC with the more stable solution. The issue that everyone on a project should be on a same page.

## Popular solution

In most cases, developers think it is enough to write `TODO` item in their code. But imagine if you have 40 repositories for micro-services on a big enterprise. How will you collect all TODO-s? Scan the sources? Okay, but how will you track progress? If you do not see how much you have done - you do not feel happy.

Here I would like to lead to my way of technical debt management.

## More precise solution

I propose to use the next structure as a table. You can extend the structure with additional columns, but please - do not shrink.

- Number
- Issue
- Cause
- Solution
- How to prevent?
- Initiated
- Solved
- Status
- Assignee

Seems big, but let me dive in and describe every point in details. Except for Number - an auto-incremental stuff.

### Issue - Cause - Solution - Prevention

The issue used for code-name, which will help you find and identify an item. But any issue has a root cause, and it is critical to define the cause.

When you fill the Cause column answer next questions: Why/How/When an issue occurred? Questions will help you define a root cause and understand who made a mistake and why.

When you know the root cause - you can fix an issue. And it is the best time to describe your solution. You can brainstorm with a team and write the solution, so everyone will be on the same page.

And do not forget - in future you need to prevent that issue. If you have the same issue over 3 times - you have a problem in your development process and something is going wrong.

### Initiated vs Solved

Initiated means that you found or created an issue in some period. You can write the date, but I prefer to write the number of a Sprint or Iteration. In a such way, you can analyze a table and see a correlation between rush-sprint and increased technical debt.

And also do not forget to write when you solved an issue. If you do things right - you can build such chart.

![Resolution chart](https://thepracticaldev.s3.amazonaws.com/i/17discf68arrue5xt6zv.png)

You can use resolution chart to define when you made a lot of invalid descisions. Also, you can find out that you forgot to fix debt for a long time. Non-stacked area chart is best for that case. For vertical axis - use amount of total/resolved issues per sprint or date.

### Status and Assignee

You can use Jira or any other task tracking system or do not use it at all. But please - do not remove a completed item from the table. Otherwise - you will not be able to track a progress and amount of completed stuff. Also do not forget that you wrote how to prevent that issue in future.

### Example of an item

Here I provide an example of an item in technical debt.

| Column | Value |
|-|-|
|Number           | 13 |
|Issue            | Outdated README file|
|Cause            | After creation of landing page, there were changes in a folder structure |
|Solution         | Update the file |
|How to prevent?  | Update the README file right with changes in structure in the same Pull Request |
|Initiated        | 21 |
|Solved           | 25 |
|Status           | DONE |
|Assignee         | Aleksey Pastuhov |

Here I want to note that you can fix an issue in time, it is simple prioritization.

## Summary

Remember that you should monitor your debt iteratively, and take tasks into your sprints to get things done.

This is how I prefer to keep and manage technical debt. If you do right, you will have positive results:

- A motivated team
- You will be able to control technical risks
- If there are no requirements or design - you have a lot of stuff to do
- And you will be able to debate to your manager or a client that you need a sprint for code stabilization

Share your feedback and let me know how you used to manage technical debt.
Send me a [message](mailto:aleksey.pastuhov@gmail.com) or [tweet](https://twitter.com/PastuhovAleksey)!

P.S.: Do not forget about prioritization! Just add “Priority” column, if it's required in your case.

Originally posted on my blog [apastuhov.com](http://apastuhov.com).

## Useful links

- [Technical Debt Causes](https://en.wikipedia.org/wiki/Technical_debt#Causes)
- [Technical Debt by Martin Fowler](https://martinfowler.com/bliki/TechnicalDebt.html)
- [3 main types of technical debt](https://hackernoon.com/there-are-3-main-types-of-technical-debt-heres-how-to-manage-them-4a3328a4c50c)