Technical debt is a business problem

Martin Fowler explains in his technical debt quadrant the four different types of technical debt – reckless, prudent, deliberate, and inadvertent, but there are more. Developers are usually forced to introduce a new technical debt as companies keep trading quality for short-term goals, such as new shiny features. Yet Technical Debt doesn’t only impact the whole organization but also developers’ happiness and job satisfaction [3]. 

The image below shows how technical debt reduces teams’ ability to develop new features. 

Types Of Technical Debt 

 There are several types of tech debt: 

1. Code quality – our code could be clearer to understand. There are no coding standards, it’s poorly designed, and there is a lot of complexity. In addition, there are a lot of code comments explaining what something does. 

2. Testing – we need a proper testing approach (check Test Pyramid), from unit tests, over integration to E2E tests. 

3. Coupling – between modules that block each other increases the time to deal with such code. 

4. Out-of-date Libraries or Tools – we are using some legacy libraries or tools with several issues, such as security or inability to update to new technologies and platforms. We, as developers, always want to work with the most up-to-date technologies and efficient tools. 

5. Manual Process – some processes in our delivery need to be automated. No automated builds, no CI/CD process. 

6. Wrong or no architecture – we don’t have proper architecture, or it’s just a big ball of mud. Our architecture doesn’t reflect what we want to achieve with our system, or it doesn’t scale well. 

7. Lack of Documentation – there is no documentation, or it’s not updated to reflect the system’s current state. 

8. Lack of Knowledge Sharing – we don’t have a culture of knowledge sharing, so it is not easy for newcomers to get up to speed. We should always document our decisions and specifications during our work. 

And there are more types, too, regarding low-value work, issues with monitoring, etc. 

Yet, we often see in many organizations a need for more processes and strategies to manage and reduce technical debt and a sign of needing proper engineering culture. 

Strategies to Fight Technical Debt 

So, what are some strategies to reduce technical debt? We should all start by prioritizing Technical Debt. First, we need to analyze our development process and codebase to find bottlenecks and create a Tech Debt Map. Then, once we have such a map (shown in the image below), we need to review each piece by identifying causes. 

Now, when we have this list, we can go through it and check what happens if we do nothing (could it become worse or not) and if this part of our system is used for new development now and in the future. So when we mark these two things, we can prioritize and keep stuff with worse tech debt, and we will build on those now and in the future. 

Also, another alternative is to build this map in terms of effort and pain to fix issues or the RICE Scoring model. 

You can also organize a workshop or Tech Debt retros to build a map, and you should regularly audit debt across all of these categories. 

A Recommended Strategy to Deal with Technical Debt 

One recommended strategy to deal with Technical Debt consists of the following steps: 

1. We need to be transparent about our development, bottlenecks, and why we need to go faster. Then, we need to summarize this in a language that allows all stakeholders (engineering and management) to share the same understanding. Then, Here visualizations help a lot. 

2. Our systems need to have clear ownership and be responsible entirely for them. But, unfortunately, if some parts of our system aren’t right, no one is taking care of them. 

3. We need to prioritize stuff based on impact, as we showed on the Tech Debt Map above. 

4. We must empower teams to fix problems and resolve Technical Debt in the natural flow of product development. We need to have a healthy balance here between reducing tech debt versus adding new functionality with a pragmatic approach. What works well is to continuously invest 10-20% of development time into this.  

How you can do this: 

1. For smaller debt (up to a few hours), do a refactoring when you touch it. But, then, let people be Good Boy Scouts. 

2. For medium debt (from a day to a few days of work), you can try the following: 

1. Tech Debt Fridays are working only on this. 

2. Mark tech debt as a feature, prioritize it, and work on it. 

3. For more significant debt (from a few weeks to a few months): 

3. Take fixed time for tech debt. E.g., take a story and work two days on it. 

4. Have a special task force (dedicated team) to handle it for some time. 

5. Use metrics, such as code issues (e.g., by using SonarQube) or lead times. These metrics can help us to make better decisions around fixing Technical Debt. 

Tools to track Technical Debt 

You can track your tech debt with several kinds of tools. I recommend just using existing tools not adding cost or complexity by introducing new tools. 

Technical Debt can be tracked in the following ways: 

1. Project management tools – the tools such as Jira, Asana, GitHub issues, Azure DevOps Board, or some more specific tools for this, such as Stepsize or CodeScene. 

2. Automated code analysis tools – you can use tools for code analysis, such as SonarQube, to track and detect code issues as well as security issues or other problems. 

3. Manual tracking method – such as Excel table or whatever works for you. It can even be a combination of the above methods, such as tracking strategic Technical Debt in Miro, tracking tactical Debt in Jira, and using metrics from SonarQube. Just make it accessible and easy to update. 

Keeping Technical Debt Low 

The question is how to avoid creating tech debt in the first place. The answer is to have a high-quality software development process. And here are some things we can do: 

1. Architect systems for the desired outcome. Involve architects from the start in the creation of teams by defining their topology [7] because otherwise, Conway’s Law [5][6] will make our architecture to be an image of our organization’s communication channels, not desired architecture. 

2. Write documentation for all your architectural decisions (ADRs) and technical documentation. Make it easy to find (place it in the repo near the code). 

3. Write tests on all levels of the Testing Pyramid. Aim at 60-80% of code coverage. 

4. Encourage a code review culture. Involve everyone in code reviews and check for code readability, design, performance, security, testability, and documentation. It is one of the best ways to share knowledge. 

5. Pair Programming works where one developer writes an ode while another provides feedback and suggestions. This results in higher code quality; with this implemented, we don’t need code reviews. 

6. Allow developers to refactor. We should build such a culture that there is no need to ask permission to fix technical debt! Especially if it’s something that can be done in a few hours. 

7. Follow codebase standards, such as design, naming, and architecture. Then, automatize this through tools such as linters or your CI/CD process. 

8. TDD (Test-Driven Development) is a software design process where each functionality is designed by writing a test first and then doing a proper implementation. 

9. Write high-quality code. Educate your developers first to know their programming language in-depth and understand OO concepts, design patterns, refactoring, clean code principles, architecture patterns and styles, and SOLID, YAGNI, KISS, and DRY principles. 

10. Continuous Delivery. Code is adjusted in short cycles, so it’s always easy to verify by other team members. This method avoids making significant issues in production by employing frequent releases and fast feedback. 

References