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 prudent and deliberate decision on debt and have a plan to service the debt and make our payments. So to do that, we need a debt management plan.
- Register new debt – The 1st step is to register our debt. Whenever we make a decision to take a shortcut or a quick and dirty approach, then 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, because 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. It is important to highlight the gains achieved now by taking on the debt as well as the ongoing impact (Low, Medium, High) or interest payment. Equally important is to keep reminding stakeholders of the debt and estimating ongoing impact with every new Story that comes in. That is, here is the typical estimate if we had clean code, but because of the ongoing debt and extra complexity, here is the more realistic estimate. This way stakeholders are constantly reminded of the interest payments that are being made.
- 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 Lifecyle Expectations which categorizes things in terms of changegability, maintainability, security, reliability, testability, efficiency, portability. The SQALE approach is also available in SonarQube.
- 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 amount 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 number is not an accurate number by any means, but a guideline to use in conversations instead of talking about code duplication, test coverage etc…
- 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.
- Establish a debt payment plan – When faced with different types of debt, where do we start? Well 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 and execute on it. Don’t quickly jump on 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 are paying. 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 and consider it as a low interest debt and focus on the higher interest debts first.
- 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 it 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 and not increasing, and over time, it is 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.
In this next post, we’ll discuss how Scrum teams execute on a technical debt management plan.
