Technical Debt Repayment Plan

English Original: Technical debt:a Repayment Plan

　　What is technical debt?

Many teams are plagued by technical debt, but few teams can really design a plan to break free from it. In order to better understand how to get rid of debt, we first have to correctly understand what is technical debt.

Technical debt is incurred by teams who deliberately make poor technical decisions for short-term project benefits. For example, to get a product to market faster, the team might not write in-depth automated testing, as in the face of a tricky piece of code. Or they might decide to build a project based on a framework that will soon be out of date, rather than spending money on an upgraded, service-supported version of that framework. Regardless of the decision, the key is to realize that the real technical debt is the team's deliberate decision to make long-term debt in order to gain short-term benefits.

This means that many of the things we usually blame for "technical debt" are actually not debt at all. For example, as the system becomes more useful, the team will not always be able to maintain best coding practices, in which case "bit decay" is normal, not debt. Alternatively, the team's voluntary technical decisions were found to be incorrect at the time of implementation, and this was not a technical debt. In either case, the team did not deliberately make a poor long-term decision in order to gain short-term benefits. This difference is important because we can only agree on what constitutes a technical debt, and we are able to make the best decisions on how to reduce the technical debt.

It is also important to consider the impact of the debt that we inadvertently introduce into the code base. However, since this type of debt is not intentional, we cannot plan how to resolve it in advance. In these cases, we must prioritize and resolve this debt when we find it ... As the team solves the newly discovered bugs.

　　A financial metaphor

We often compare technical debt to financial debt. But is this a reciprocal analogy? For example, would banks really be willing to lend us money without first determining when and how to repay? Very likely not willing. Since we do not first describe how to repay the debt, we are indeed unable to borrow financial capital, then we should not treat technology capital in this way.

The financial analogy is indeed very effective, so we will discuss it more fully.

　　Repayment plan

As with financial debt, when talking about technical debt, we need to identify two things: how to repay debt and when to repay it.

　　How to repay the debt

Let's take the example of giving up automated testing as we mentioned earlier. If our team voluntarily decided to give up the automated tests for tricky pieces of code in order to get into the production environment as soon as possible for a feature, we need to determine how we will correct that debt. In this case, we just need to show that we will go back to this code at some point in the future and then add the test. However, just stating that "we will be adding tests later" does not solve this problem properly. To help stakeholders really understand how our decisions affect the technical debt, we need to do our best to accurately explain the impact of adding automated tests until later. For example, we should indicate the code snippet that needs to be added to the test. We also need to make it clear that adding automated tests to existing code snippets is harder and more expensive than adding tests directly when the code snippet is created. This last point is important because it makes it clear that by postponing this work until it is finished, we are actually spending more money on the job than we do now. Other words...... Debt is the result of interest.

After discussing the repayment method, the team and its stakeholders may realize that the problem is more complicated than whether they should write automated tests when writing code. In fact, they may find that between two extremes, they do have a variety of options that are better suited to the entire project. For example, they may decide that using an indicator such as "cyclomatic complexity (cyclomatic complexity)" to identify the most complex parts of a new feature is very meaningful, and immediately add tests to cover those aspects and postpone the simpler aspects. Or, they might decide that automated test types, such as unit testing, which are simpler but also of lower value, can be added immediately, but more difficult automated tests like automated user acceptance testing can be postponed to future sprints. Regardless of the decision, the team and its stakeholders are unlikely to make it because they are not discussing the technical debt at the first time.

　　When to repay the debt

In addition to specifying how to repay the debt, we would also like to indicate when to repay the debt. Usually, the sooner the debt is repaid, the better. For this reason, it is advisable to arrange debt repayment at the time of the debt generation in order to better communicate the impact of the debt burden. For example, if your team follows a schedule made up of sprints, you might choose to schedule the work to the next sprint, or, in the worst case, no more than a few future sprints.

Usually, the team has the best desire to repay the debt when it appears, but they just never seem to have the time to do it. When you want to eliminate debt, write down the deadline on the calendar and keep it on schedule.

　　What happens if a breach is breached?

The last part of our financial analogy is to figure out what will happen if we choose to default on debt. In the financial field, if I never repay the car loan, the bank will take my car. The consequences of defaulting on technical debt should also be clearly stated.

Let's continue the example of automated testing, if the team decides not to repay the technical debt, then building new functionality based on existing untested functionality will only make it more difficult and more expensive. In a production environment, we may see more bug reports, which means that customers may have a bad impression of the quality of our products. Our ability to respond quickly to changes in the market can also be undermined by the fact that a large part of our product is either difficult to modify quickly or that the risk of rapid modification is too high.

All of these points need to be made clear to the stakeholders to help us avoid the temptation of technical debt defaults.

　　Coping with bit attenuation

So far, everything we've discussed is focused on the planned technical debt, which is the deliberate debt of the team as part of a normal project, and if we don't discuss unplanned technical debt, we are remiss because they also plague many projects: bit decay.

As mentioned earlier, bit attenuation is not what we intentionally incur, we cannot decide in advance how and when to repay, in this sense it differs from normal technical debt. However, although we do not know exactly what the bit attenuation is in our project, it does not mean that we cannot plan it.

As we planned to repay the known technical debt, we can also include a buffer in our project plan to handle bit decay in each sprint. While it may not be possible to know the specific task of populating this buffer at that time, there is one such buffer there that gives us a dedicated space to deal with unplanned problems such as bugs, small-scale refactoring that must be dealt with immediately, or a small block of system maintenance that we call the code base natural aging and decay.

But what about bigger problems that can't be solved with a few hours of development time? There may be more systemic problems that are troubling us, such as infrastructure failures or an aging architecture that can no longer meet business needs. Because these problems are too large to solve, we can use this buffer to identify and study these issues, so that we can follow them in the project to give them the attention they deserve. For example, in the case of infrastructure failure, perhaps we can identify the most frequently faulty parts of the infrastructure so that we can add stories to the backlog to replace them. We then prioritize and schedule those stories in the normal development. Or, in an aging architecture, we can take some time to determine what the most valuable modifications we can make to the architecture dynamically, and then break those changes into stories that can be segmented in a future sprint. No matter what the problem is, having time to identify the problem and make a plan means that it can be solved like any other technical problem.

　　Budget

Now that we have a better understanding of the impact of technical debt, how do we really ensure that technical debt is repaid? In order to have a sensory understanding of this, we extend the aforementioned financial analogy to another direction ... Budget.

Many of us earn a fixed salary every few weeks. This wage is part of the annual wage, which is evenly distributed throughout the year. For example, if we can earn $52000 a year, we may receive $2000 every 2 weeks ... That means, 26 times a year.

However, although we receive a $2000 salary per rule, we are unlikely to be able to deposit all of them in our current account. Instead, we are more likely to keep part of the current account and use the rest for long-term investments or debt repayment. For example, we initially had a $2000 deposit, and the budget decomposition might actually look like this:

• $500 for long-term investments, such as depositing into retirement accounts

• $200 to repay short-term debt, such as credit cards

• $300 to repay long-term debt, such as mortgages or car loans

• $250 Direct deduction to cover local or national taxes

• The remaining $750 is deposited in a current account.

Now, although no one is particularly excited about this arrangement, it is hardly questioned. In a way, it is simply an accepted norm. Since this arrangement is so widely accepted, why not extend it to our project plan?

Imagine we're planning a sprint for a story point, and we've allocated 50 story points for that sprint. While we want to use all 50 points for new developments, in practice, the most logical way is to arrange some points for repaying technical debt. For example, for the original 50 points, we may decide to arrange:

• 10 points for repayment of technical debt

• 5 points for uninterrupted code base maintenance, such as fixing bugs or processing bit decay

• 35 points for new development

Looking at our point budget, we can see that it has some obvious similarities to the financial budget we described earlier. Although we have 50 points per sprint to do things, not all of those points are used in new developments. Rather, we have to use 10 of those points to repay the technical debt that we intentionally incur, just as we use a portion of our salary to repay our long-term and short term debts. In addition, we use 5 points exclusively for maintaining uninterrupted code base maintenance, as we use a portion of each payroll for tax purposes to help maintain the normal functioning of our community. The remaining points are our own and can be used for any new development according to our wishes, as the rest of the money is deposited in a current account, which we can freely dictate to our own volition.

Through the work budget, we can ensure that our project is still moving forward without allowing it to collapse under the weight of technical debt.

Of course, like a personal budget, the budget is biased. For example, if we repay technical debt faster than expected, then we will have some remaining story points that can be used in the development of new features. And again, if we find that we are taking on a particularly large amount of technical debt, then we may need to reduce the development of new features slightly until the number of technical debt returns to a more manageable level.

　　Summary

By considering technical debt by analogy with financial debt, we can have a better judgment on when it will incur technical debt and help improve the project. In the course of the project, we can also better plan the impact of trying to repay the debt.

Moreover, by planning daily budgets in daily work, we can better understand when our debt is manageable and when it will overload us.

Technical Debt Repayment Plan