What purpose will NRC implement

Felix Müller, Eberhard Wolff 10

Every developer knows the problems associated with maintaining and changing old code bases. The code is poorly structured, there are few tests, and the versions of the libraries used are quite old. Many things are also implemented much too complicated. The metaphor of "technical debt" is used to better communicate these technical problems to management.

The idea behind the metaphor "technical debt" is to see the quality compromise as guilt. It can even be quantified: It is the effort or the costs of "repairing" the code base - that is, to improve the structure, to write the corresponding tests or to switch to new versions of the libraries used.

Interest is also payable on debts. In the tech debt metaphor, interest is the team's decreased productivity in implementing new features. The first intuition with technical debt is to remove it and reduce it. But that doesn't always make sense. On the contrary: Additional technical debts can be incurred in order to implement a new "quick & dirty" feature. In that case, the team sacrifices quality for an advantage in time-to-market. In the long term, the productivity advantage turns into a disadvantage due to the "interest rates", so that one has to be careful with taking on debts (Fig. 1).

There are different approaches to paying off the debt. Every developer should make minor improvements in their daily work. But if major changes are pending, the effort must be planned in and somehow included in the budget. There are many different approaches to this - an InfoQ article elaborates on a few. The metaphor of technical debt should help in the discussion about such a budget. After all, she comes from the financial world, an area managers should be familiar with.

The team can now make a statement and, if necessary, estimate the cost of paying off the debt. Tools like SonarQube can help with this. Often the effort for "tidying up" the code base is quite high (Fig. 2).

In responsible management, this approach can create difficulties. After all, there are obviously hidden costs and technical risks associated with the project. Where should the budget for these expenses come from? By the customer? But they're not features. In the end, the developers often don't get a "go" for extensive improvements. In this situation, you make the decision on how to deal with the technical debt yourself.

It's partly professional - after all, a focus on quality is a sign of a professional approach to work - but if days were to be invested in improvement, it should be a management decision. The effort must be prioritized against the implementation of features and time-to-market. This should not be done under the "management radar", unless the developers "price in" the effort involved in implementing the stories - for each feature, think about whether the code should be improved beforehand so that the feature can then be implemented more easily . In any case, this makes it clear that the metaphor of technical debt does not necessarily help to illustrate the quality problems to management and to prepare meaningful decisions.

The problem with technical debt

The quality of the code has one decisive property: It does not matter at all - as long as the code is not to be changed. But then quality is extremely important. So the main problem is: which debts do not matter and which are extremely important? Which debts should be paid off and when? At this point, the metaphor of technical debt alone does not help.

The technical debt has nothing to do with the successful completion of a project. But in the end, in some situations, economically senseless decisions are made. If quality is neglected in the long term, productivity continues to decline - something managers in particular do not find useful
can. Developers can anticipate such situations and then often have a bad feeling, but they cannot prove it or communicate clearly to management.

Another term from the world of finance can be used for this: investment. When developers improve the quality of their code, that's an investment. It only makes sense if higher productivity can be achieved in the future. Quality is not an end in itself, but facilitates changes to the code base, thus influences productivity and is therefore of economic importance. So the basic idea is that quality improvements are an investment. They are useful if the improvements save more effort than is necessary to implement the improvements. It would be ideal if a return on investment could even be calculated for the quality measures.

Quality investment

Quality Investments: The New Metaphor

The quality investment metaphor thinks technical debt further. These are the costs that have to be raised to remedy quality defects. The quality investment makes it possible to estimate a benefit from these costs, which ultimately results in a profit.

The SQALE method (Software Quality Assessment based on Lifecycle Expectations), a quality model, formulates two types of costs: remediation costs (RC) and non-remediation costs (NRC). The former arise when a quality defect is rectified. They are to be equated with the technical debt. In contrast, the non-renovation costs occur when a quality defect is not remedied - that is, you continue to work with the poor quality. Previous implementations such as the SQALE plug-in from SonarQube only use the renovation costs. The key to an economically sensible approach to quality lies in both types of costs.

If you clear up the code and correct the quality defects, the renovation costs are due. However, the team then saves the non-renovation costs. It is therefore worthwhile to improve quality only where the non-renovation costs are greater than the renovation costs. Because then the investment in quality results in a profit. This can be easily described with this formula:

Profit = NRC - RC

Whenever remedying a quality defect is cheaper than living with it, it is worth investing in quality. As mentioned, quality only becomes more important when the code is changed. For the profit calculation shown, this means that the non-renovation costs only occur if the code is touched in the future. Because only then does the team slow down due to the poor quality. For the investment consideration, in addition to the two types of costs, the probability of change in the code under consideration must also be estimated. Therefore, the metaphor of quality investment can be implemented with three estimates. An example may illustrate this.

A fictitious system consists of three components - for example for the management of customers, orders and the warehouse. Customer management is very old and is no longer being developed. For a quality investment, this component is therefore subject to a loss, since the non-renovation costs will occur with a probability of 0 percent.

The situation is different with the components for warehouse and orders. It is known that extensive changes will be made to the ordering process in the next iteration. Based on experience with the further development of the system, it is also known that changes to the ordering system have a low probability of causing changes to the storage system. It can therefore be assumed for the ordering system that larger parts of the code will be changed, while changes are also made in the warehouse system, but not to the same extent. Such rough estimates are usually sufficient, and it is also easier to agree on such a value. Experience shows that more finely granular estimates usually only simulate a precision.

In a further step, the quality defects in these two components are to be estimated. For example, there is the underground test coverage in the ordering system or the close coupling of classes in the storage system. Refurbishment and non-refurbishment costs are estimated for all striking points. Ultimately, the non-renovation costs result as the difference between an estimate of the implementation effort with and without the quality investment considered. It is important to include the probability of change in the consideration. The non-renovation costs in the ordering system are not only particularly high because the quality is so poor there, but also because extensive changes have to be made:

  • Ordering system: low test coverage, RC: 3d, NRC: 5d
  • Storage system :, close coupling, RC: 2d, NRC: 2d

So there is a profit of two days for the ordering system (= 5d-3d), while no profit is to be expected with the storage system. It is therefore clear that it makes sense to invest in the ordering system at the moment, as the team estimates that improving test coverage promises a profit. At the same time, investing in the storage system does not make economic sense - but if changes in this component are foreseeable in the next iterations, it could still make sense to improve the quality here. In such a case, the planning horizon for the quality investments can be greater than that for the features, which makes the weighing up more difficult.

Once the profit has been determined, it can be used to calculate the return on investment, a parameter from the financial world that indicates how much profit is generated in relation to the investment of funds. To do this, divide the profit by the renovation costs. For the quality investment in the ordering system in this example, this is an ROI of around 67 percent (= 2d / 3d). This number can be used to show the manager the benefits of investing in quality.

The quality investment metaphor allows for a different kind of discussion with management. Instead of a cost value for the technical debt, the manager can be told that tidying up a component saves time and effort in the foreseeable future. For the manager this means a win-win situation: budget is saved and the developers are satisfied because they can improve the code quality. The manager can also weigh up whether the investment makes sense or whether a "Quick & Dirty" development is sufficient or perhaps even necessary because of the time-to-market.

Ultimately, the quality investment is a weighing of different estimates of what makes the most economic sense. The question arises, however, why software developers are not making much more use of the idea of ​​an investment. Investment accounting is not a new invention, and software is an asset that money has been invested in. To speak of debt incurring in this context actually seems strange.

CodeQ Invest

A tool for quality investments: CodeQ Invest

With a large software system, estimating the quality investment can be a hassle. It can also be difficult to determine the likelihood of individual components or classes changing. Therefore, a tool was created that is supposed to help with the estimation and enables a better overview of a code base: CodeQ Invest, which is licensed under the GPL.

One advantage of the tool is that it supports you in estimating the probabilities of change. It can be estimated directly as a value or determined based on the history of the version control system. It is assumed that past changes enable a statement to be made about future changes - this is of course not always the case. Therefore, when the team provides a manual estimate for individual files, packages, or modules, that is used as the probability of change instead. One of 100 percent means that every file viewed is definitely changed. Since the probability of change determines the occurrence of the non-renovation costs, this factor must be included in the profit statement:

Profit = NRC * Probability of Change - RC

At CodeQ Invest, the team formulates quality requirements that express a desired quality optimum. So that the analysis of a code base with a number of quality requirements can take place automatically, the requirements are defined in the form of a limit value of a metric. To stick with the example from above, there would have to be a quality requirement for the ordering system that states that the test coverage must not be less than, for example, 80 percent. The renovation and non-renovation costs are also estimated for each quality requirement. It is important that the periods and components considered are not too small. Otherwise the impression of micromanagement emerges later. With the stored quality requirements, the code files of a given software system are automatically analyzed. All the necessary estimates are now available.

CodeQ Invest aggregates all cost values, estimates and profits in different views. A zoomable tree map shows the code base and the investment potential at different depths, and bar charts enable different investment amounts to be compared based on the ROI (Fig. 3).

CodeQ Invest can currently be used in Java projects. However, SonarQube must first be installed so that the metric values ​​can be loaded. Subversion is currently supported to determine the probability of change based on version control.

CodeQ Invest is a tool that can help in the implementation of quality investments. At its core, estimates are still needed for the team to make. The values ​​determined by the tool depend on which values ​​are set for the RCs and NRCs of the individual quality metrics and, if applicable, on the manually estimated probability of change. Before using CodeQ Invest, consider how the introduction of quality investments works better: with rough manual estimates for large cleanups (top down) without tool support or with a tool where the estimate works "bottom up". In any case, the tool can provide an interesting insight into the quality and change history of the system.


Although the metaphor of "technical debt" is widely used, it is not constructive: it points to problems but gives no clues as to how to solve them. It just measures the quality of the code. And that information is completely irrelevant until the code is changed. But then the quality is decisive.

To deal with this problem, the metaphor of investing in quality can be used: every improvement causes an expense. It only makes sense if this effort is foreseeably saved when the codes are changed due to the higher quality. This consideration can either be the basis of an assessment or it can be supported by CodeQ Invest. In any case, this creates the basis for an economically sensible use of software quality, so that developers and management can pull together. (ane)

Eberhard Wolff
works as a freelance architect and consultant. He is also a Java Champion and head of the adesso AG technology advisory board. His technological focus is on Spring, NoSQL and Cloud.

Felix Müller
works as an IT consultant and software developer at codecentric AG. He deals with the development of web applications in the Java environment. He is particularly interested in test automation, continuous delivery and agile procedures.

  • Thomas Haug; Everything in view; Use of SonarQube for quality assurance in heterogeneous projects; Article on heise developer