In the previous blog, we looked at how when we don’t actively manage our debt, it can lead to a vicious cycle we can’t get out of. We want to make a prudent and deliberate decision on technical debt and have a plan to service the debt and make our payments. To do that, we need a debt management plan. Here are six steps to successfully implementing a technical debt management plan:
1. Register New Debt
The first step is to register our debt. Whenever we make a decision to take a shortcut or a quick and dirty approach, we need to log our decision and add it to our technical debt backlog, along with an estimate of how long it would take to fix. The estimate of course only makes sense if we are going to pay the debt off immediately. Usually, the longer we wait, the longer it will take to apply the fix and our initial estimate becomes invalid. Our technical debt register provides visibility into the prudent and deliberate debt decision we are making and when we plan to pay them back.
2. Assess Existing Debt
What about debt in our existing code base? And what about the inadvertent debt that we might be piling on without knowing it? For that, we have to inspect and assess the level of existing debt we have and also register it. Luckily, there are tools that help us do that. SonarQube helps us assess debt across multiple categories like duplication, rule violation, code coverage, complexity, documentation, etc… and provides us with multiple ways to visualize the debt and plan on how to pay it back. Another method is SQALE or Software Quality Assessment based on Lifecycle Expectations, which categorizes things in terms of changeability, maintainability, security, reliability, testability, efficiency, and portability. The SQALE approach is also available as a plugin in SonarQube.
3. Monetize the debt
Now that we have visibility into the state of our existing code base and a log of our new debt, the next step is to monetize it. Monetizing the debt allows us to use a single unit of measurement to describe the different types of debt and talk about our debt in terms of dollars and in a language that management can understand. To do that we estimate the number of hours it will take to fix each type of deficit and multiply it by the total number debt deficits. Luckily, the technical debt plugin in Sonar can provide us with this calculation. It is important to note that this is not an accurate number by any means, but a guideline to use in conversations instead of talking about code duplication, test coverage etc.
4. Establish a Debt Limit
What is a good amount of debt? Well, it depends on your appetite for risk. Some people do not like to be in debt, others take calculated risks. The key here is to manage and monitor it and when we reach a certain threshold we should say we are not keeping up with our minimum payments and we need to slow down on new features until we have our debt under control.
5. Establish a Debt Payment Plan
When faced with different types of debt, where do we start? Once again, it depends. Does the team know how to write tests to increase code coverage? Does the team know how to reduce complexity? If not, come up with a training and coaching plan. Does the team understand the rules they are violating? If so, start there. How about removing duplication and refactoring? Where to start is going to depend on the team’s skill sets and level, but the key is to put a plan in place and execute on it. Don’t quickly jump to the most complex class. Remember, there are long-term debts and short-term debts. We want to first reduce our short-term debt which is usually like credit card debt. This kind of debt has the highest interest rate. In code, this means we want to tackle first the classes that are constantly changing the most. The more changes we make the more interest we pay. If we have a class with no test coverage at all or one that is very complex but is never or rarely modified, we need to leave it alone for now. Consider it a low-interest debt and focus on the higher interest debts first.
6. Continuously Monitor the Debt
Once we have visibility into how much debt we are taking on, a debt limit we are comfortable with, and a plan to pay the debt down, we need to continuously monitor our technical debt and make sure it is trending in the right direction. Hitting a specific target is less important than monitoring a trend line and making sure it is heading in the right direction. At a minimum, we want to make sure our debt is staying stable, not increasing, and over time, gradually decreasing. You will never be in a debt free state in software and that should not be the goal. Instead, we want to monitor the debt and keep it manageable and take on debt as appropriate to take advantage of market conditions and opportunities.
The Technical Debt Management Plan is the sixth in a seven-part series on Technical Debt from Excella Software Development Lead Fadi Stephan.
Part 1: Top 4 Symptoms of Bad Code
Part 2: Top 5 Reasons Writing Bad Code Happens
Part 3: What is Technical Debt?
Part 4: Good Technical Debt vs. Bad Technical Debt