Understanding the technical debt metaphor (1) means that inherently when we deliver software there is some amount of technical debt in the code that hinders on going evolution and maintenance activity. At a basic level of understanding, one is tempted to consider the instances of technical debt in a software product as static entities that do not change as the software evolves. However, as software undergoes maintenance and development activity, prior decisions to take on technical debt could lead to further accumulation of debt.
Consider an example of a subject application that has a dependency on a specific version of third party software. Developers code the application using the API library of that software. After the subject application is released, the third party software releases a new version. The developers decide to stay with the old version of that software rather than upgrade because upgrading changes the API. This is the first instance of incurring technical debt. Each release of the subject application builds further capability using the old API. The third party software also has further new releases which the team decides to ignore each time. Thus, more technical debt principal is accumulated whenever the decision to defer an upgrade is made. This combined with the interest cost of working with the old libraries creates a multiplicative effect on technical debt making the cost to pay the debt climb higher than the original decision ever planned for.
A similar example is provided by Nughoro et al. (2) who estimate that debt increases as the size of the software increases during maintenance efforts. They estimate software growth in their model as a percentage of effort applied to maintenance. The growth is modeled in an equation that results in linear growth of the debt during maintenance. While this may be the case, we should also consider other causes of debt growth such as proposed here of dependencies on antiquated software. Zazworka et al. (3) discuss technical debt interest payments in terms of additional defects and changes for code with increased technical debt. These are factors that contribute to interest payments, but we should also consider factors that increase principal.
Considering the idea of increasing principal raises the question of what the growth rate of the principal might be and what the contributors to principal growth are. When decisions are made to put off upgrading, to put off paying technical debt, and to delay fixing defects, they result in an increase cost of maintenance. In the first case we outlined here each decision not to upgrade the library results in more future work to migrate to the current version. Decisions to put off paying technical debt and to delay fixing defects are related such that developers will take extra time (interest) to work around the debt or defect when making future changes, and they will accumulate more debt in the code that performs the workaround that must be modified when the original debt is paid down at a future date. Could the function become exponentially increasing due to decisions constantly made to work around existing instances of technical debt? This is a proposed topic of future study determining what the growth rate possibilities are in this type of example and other examples.
1. P. Kruchten, R. L. Nord, and I. Ozkaya, “Technical debt: From metaphor to theory and practice,” Software, IEEE, vol. 29, no. 6, pp. 18-21, Nov. 2012.
2. A. Nugroho, J. Visser, and T. Kuipers, “An empirical model of technical debt and interest,” in Proceedings of the 2Nd Workshop on Managing Technical Debt, ser. MTD ’11. New York, NY, USA: ACM, 2011, pp. 1-8.
3. N. Zazworka, A. Vetro’, C. Izurieta, S. Wong, Y. Cai, C. Seaman, and F. Shull, “Comparing four approaches for technical debt identification,” vol. 22, no. 3, pp. 403-426, 2014.