In this blog post I will describe an approach to prioritize technical debt in an Enterprise application which is under continuous development. But why should you prioritize it at all?
Let me start by explaining a little about technical debt. Over time the technical debt is built up and it can actually be much larger than you would imagine. Maybe the debt is caused by a mistaken code practice which might not be the right fit. This for example, could be a switch case over an enum where you do not have a default, or it might be using X509Certificate2 (.Net System.Security.Cryptography.X509Certificates) without calling the Reset method afterwards. As a product owner, or other stakeholder, you may suddenly be made aware of the technical debt. This could for example, be due to a transition from 'convention' (agreements on how to code) to 'structure' (addition of static code analysis tools, such as Resharper or SonarQube).
It is necessary to start prioritizing the technical debt because you rarely would have the time to deal with all the debt at once. Even if you had the time, it is relevant to decide whether your goal is to completely eradicate all the debt or not - perhaps you consider that the time is still better spent on further development on the application itself.
Let me introduce an example application. It has many hundreds of thousands of code lines and has been developed over several years by a large group of skilled developers who have been working by the test driven method, with great code principles and code reviews ('convention'). By letting SonarQube do the static code analysis, the focus was suddenly put on technical debt. where 31,000 issues were identified. They were distributed on severity like this: