The concept of technical debt is closely related to the financial domain, not only due to the metaphor that bonds it with financial debt, but also because technical debt represents money. On the one hand, it represents money saved while developing at a lower quality or money earned when delivering the product in time, whereas on the other hand, it represents money spent when applying a refactoring.
As a result, financial terms are broadly used in TD literature. In order to work towards a framework for managing technical debt, we have attempted to organize a glossary of the most common financial terms that are used in the state of the art. The glossary presents these terms and a definition for each one. The definitions are a result of synthesizing the way that the terms are used in literature and in some cases they reflect our understanding of how these notions could prove beneficial for technical debt management.
Next, we illustrate our view on how financial terms are used in technical debt literature by employing three explanatory figures. In Figure 1, we assume a software system that is composed of 7 artifacts (e.g. software components). Artifacts 2 and 3 have been developed on the desired levels of design-time quality, whereas in all other artifacts several compromises have been made. This difference in quality is shown by the distance δquality. The immature software artifacts are named technical debt items or liabilities. While developing the aforementioned artifacts, the development team spent less effort than it was required in the optimal case. The effort that is required to address this difference in the levels of quality is termed principal of the TD. Principal can be considered as an asset for the company, since it can be used as financial leverage in order to invest in any other activity. Such activities can be the development of by-products or decreased time to market. The earning of these activities divided by the principal represents the return of investment (ROI) of investing the principal.
In Figure 2, we suppose that the same system, after its deployment, requires the addition of a feature. For simplicity, we assume that this feature is global and the same effort needs to be spent in every artifact. However, in the artifacts where technical debt is accumulated (TD items) additional effort (δeffort) is required because of their deteriorated design-time quality (e.g. low maintainability, incomplete documentation that leads to low understandability). This additional effort is the interest that the development team has to pay, due to the accumulated amount of debt. If the interest becomes so high that maintenance is not financially feasible or beneficial, the project becomes bankrupted.
In Figure 3, we consider the evolution of a system with accumulated technical debt. The two series in the line chart represent the evolution of the system without any repayment activity (red line) and with one repayment activity performed in revision-4 (blue line). We suppose that the system starts with an amount of debt that increases over time (interest rate is represented by the slope of each line, e.g., θ1 and θ2). Interest rate is not presented to be stable, but floating, since the slope of the lines is increasing over time. This increase is expected, since the design-time quality of decayed projects, deteriorates quicker than the quality of better-designed products (the poor getting poorer). Therefore, the TD risk for low design-time quality products is higher than the TD risk of high design-time quality products. We assume that the interest rate increases due to the increased difficulty of resolving existing problems, which in turn is caused by the gradual increase in size and functionality. Due to the repayment actions in revision-4, some artifacts’ design-time quality is increased, i.e. technical debt is decreased (δTD1). The effort that is spent during this repayment activity is the value of repayment. Furthermore, because of the floating rate of the interest we can see that in revision-7 the value of repayment increases, as illustrated by the distance between the two lines (δTD2 > δTD1). The value of the repayment performed in revision-4, is named future value of repayment in the timestamp of revision-7. Assuming that present time is revision-2 and that a future repayment activity (e.g. the one performed in revision-4) should be valuated at present conditions, one can assess at revision-2 the present value of the repayment to be performed in revision-4. Finally, accepting that software value is related to product quality (de Groot et al.) can lead us to the conclusion that the enhancement of design-time quality that is achieved through the repayment on revision-4 represents the value-added of TD repayment.
The question that rises and has still to be answered is whether and how the metaphor and the aforementioned financial terminology can assist the technical debt community in building a concrete conceptual model for technical debt and eventually in defining methodologies for effectively managing TD.
- Ampatzoglou, A. Ampatzoglou, A. Chatzigeorgiou, P. Avgeriou, “The financial aspect of managing technical debt: A systematic literature review”. Information & Software Technology 64: 52-73 (2015)
- J. de Groot, A. Nugroho, T. Back, and J. Visser, “What is the value of your software?”, 3rd International Workshop on Managing Technical Debt (MTD ‘12), IEEE Computer Society, pp. 37 – 44, (2012)