Invest in quality no longer have technical debt

A fairy Tale

A long time ago, a software development team found their manager. "Our project has quite a bit of technical debt (technical debt) and we should do something about it." "The team said. They showed a picture (Figure 1) to illustrate the technical debt of the project. "Technical debt is related to the quality of the project. "They said. It also shows the decomposition of various parts of the technical debt, through static code analysis, can find too complex code, duplicate code and conflict. "We need to get rid of technical debt," they told the manager.

Figure 1:sonarqube Technical Debt Plug-in Results report

But the manager was puzzled: What is technical debt? Should he add extra $500.000 to the budget? For what? It's about quality, but he doesn't know what the flaw is now. Customers have been very satisfied with what these developers are saying? So the manager and the team had a long discussion.

In fact, technical debt is a metaphor that is introduced in such discussions. It means that low quality code is like a financial burden. The total amount of debt is the effort needed to clear them out of the code base. Interest rates are due to lower productivity caused by low quality code. Managers are usually familiar with the terminology in the financial field, so using this metaphor is easier to communicate when talking about software quality.

The story shows that the technical debt metaphor has failed. This thought that when communicating technical quality with the manager, it could help and ultimately generate rewards. However, the reality is not so easy. That's because having a technical debt doesn't mean it has to be repaid. Technical debt may not even be a bad thing, and sometimes it is just a compromise for listing on time or achieving other goals of the project. Even sometimes this can not be avoided, such as the use of new technologies or upgrades to the class library, resulting in the original code of no problem is now generating technical debt. There is no simple law on how technical debt should be repaid. In fact, there are many ways to repay technical debt, or sometimes you can even use it as your advantage [1].

The problem of technical debt

The main problem with technical debt is that it represents only the internal quality of the system. And what is the effect of quality is not clear. In particular, the economic impact of technical debt cannot be simply expressed in this parable. The technical debt is still strange. If the code does not need to be modified, then the technical debt is completely irrelevant. However, once the code is modified, the technical debt becomes all the important attributes of the code. Therefore, technical debt is likely to have no effect on the success of the project or on the externally visible quality.

But if you neglect the technical debt of the project, it is likely that it will be waiting for you somewhere: if you need to modify the code with a lot of technical debt, the cost can be very high and ultimately impossible to implement. Developers often know and fear this kind of situation, the maintenance of a lot of technical debt code is not only less fun, but the risk is too high, because the bug is likely to sneak in, and evaluation can easily prove to be wrong.

Therefore, the software quality may be very important to the success of the software project, but the technical debt metaphor is not enough. It can be used to express the quality of software, let people understand how the quality of software, but how to deal with the quality of software is really important.

Quality investment: A new metaphor for fixing code

Perhaps a different metaphor would be a better indication of what we should do with the quality of the software system. The technical debt only reflects the cost of repairing the quality problem, as in the case of $500.000. This number is not useful in itself, it does not explain how we should deal with the problem, or how they affect the development of the system. Perhaps we should repay the technical debt, perhaps it has no effect at all.

So a better analogy may be the quality of investment (Quality investment). Using quality investment, dealing with technical debt is likely to earn a profit. This allows you to actively manage the quality of your code using financial terminology, making it easy to decide which quality issues should be resolved and which to accept temporarily.

The idea of quality investment comes from Sqale. The Sqale method [2][3] is a quality model that defines two types of costs: repair costs (remediation COSTS,RC) and non-repair costs (non-remediation COSTS,NRC). Fix cost is the effort to clear a quality problem in your code base. In fact, the cost of repairs can be seen as technical debt. The second type of cost is more interesting. When this quality problem is not resolved, the cost of repair is not repaired. For example, developing a new feature may take a long time. This extra effort is a cost-neutral fix. In this context, the cost of repair looks like a profit on technical debt. In reality, however, these costs should be given more consideration, such as the additional risk factors for not cleaning up low quality code. With Sqale, you can choose to maintain the current low quality state, pay the cost of the repair, or to improve the quality, pay the repair costs.

The upfront implementation of the quality model, such as the Sonarqube Sqale plug-in, only supports repair costs. However, these two types of cost are the key to the economic and rational treatment of quality, and also the innovation of this quality model.

If you are improving quality and solving quality problems, then paying is the cost of repair. When the problem is cleared, the team avoids the corresponding cost of repair. Therefore, only when the cost of repair is greater than the cost of repair, it is worthwhile to improve the quality. Because only in this way, quality investment can generate profits. This can be simply described with the following profit formula:

Profit = Non-repair cost-repair cost

This formula gives a reasonable and economical guideline for judging whether quality problems need to be repaired and when to fix them.

As mentioned earlier, the quality of the code becomes important only when it needs to be modified in the future, because only then will the team slow down because of low quality code. Therefore, the right investment analysis must evaluate the possibility of future revisions of the Code, as well as both types of costs. Therefore, the metaphor of quality investment can be achieved through three evaluations. Let's look at an example to learn more about this.

Suppose we have a system that includes three modules: Customers, orders, and invoices. Customer management is a very old module that is no longer developed. Therefore, this module is not suitable for quality investment: The repair cost is only incurred when the code is modified, in this case the likelihood of modification is 0%. So paying any repair cost will result in loss.

However, we know that the order process has been modified extensively in the next iteration. According to experience, invoice management must also make some changes. A rough estimate like this is usually sufficient, and it is easy to agree. Experience tells us that most of the detailed evaluation is to pretend to be accurate.

The next step is to evaluate the quality issues with the order module and the invoice module. The Test coverage for order management is very low, and customer-managed code is very complex, meaning that methods and classes have a lot of code and a lot of complex loops. Faced with many options, we assessed the cost of repairs and the cost of repair. The possibility of module modification should also be considered in the evaluation of the cost of repair. In the next iteration, if the code is of the same quality, order management is estimated to take 20 days. And if the test coverage can be increased, then it is estimated that only 13 days to invest. Therefore, the cost of the repair is 7 days. This is very high, because the quality is really bad, but also because there is a lot of code to modify.

Order Management: Very low test coverage, repair costs: 5 days, not repair costs: 7 days

Invoice module: High complexity, repair costs: 5 days, not repair costs: 4 days

These evaluations indicate that the quality of the order module investment generated 2 days (= 7 days-5 days) of the profit. On the contrary, the quality investment of the invoice module has no profit or even loss. It can be seen that investing in the current order system is valuable because it is profitable to increase the test coverage according to the team's assessment. For the invoice module, the situation is not clear. For now, its quality investment is not profitable. However, the invoice module is likely to be modified in several iterations in the future. This will enable you to profit from the quality investment in the invoice module.

The return on investment (RoI) can also be calculated for each quality investment, based on the assessed and calculated profits. The return on investment indicates how much profit the corresponding cost generates. Therefore, the return on investment equals the profit divided by the cost of repair. The ROI of the Order module quality investment is about 40% (= 2 days/5 days). Managers often look for opportunities to gain a higher return on investment. Using these financial terms, you can communicate with them to improve the quality of the code after the gain. Of course, like almost any other thing in software development, these numbers are estimates. However, this shows that the team is not just seeking to improve quality for its own reasons, but more importantly, for economic reasons.

The metaphor of quality investment allows you to have various types of discussions with managers. In addition to the cost of technical debt, you can discuss with your manager to save time and effort. For managers, this means a win-save situation: The budget is saved and the developers are happy because they can improve code quality. Similarly, managers can consider whether the investment is appropriate, or a fast but lower-quality solution is sufficient, even necessary, because of the listing on time.

Finally, quality investment is a comparison of the results of numerous assessments: what is the most economical decision? However, it begs the question of why the idea of investing in software development is rarely used.