Another analogy with financial debt is that it is often prudent to have technical debt.
Substandard software is often delivered quicker, generating the desired business benefits earlier. In addition, the time and money saved, can be spent on other functionality that adds value.
As long as the interest in the form of incidents is not excessive, this is often a wise decision.
It is also prudent to ensure that the technical debt remains within acceptable limits. It is therefore good practice to allocate a certain amount of the product’s budget to repaying technical debt.
This can vary, depending on how many incidents (‘interest’) occur, but it is crucial that regular repairs are made. Lehman's second law of software evolution states that as an application evolves, its complexity increases unless work is done to maintain or reduce it.
Disciplined effort is therefore needed to manage technical debt.
In order to manage technical debt in relationship with functional ‘credit’, the following items should be tracked over time:
Benefit and cost of new and changed functionality
Cost of incidents as a result of substandard software
Cost of repairs to substandard software.
These should provide enough insight into the effect of investment in repairs in the form of reduced incidents, and budgets can be adjusted accordingly.
There are, however, other investments and costs to consider. From time to time, there are updates to the platform on which the application is developed and run.
Adoption of some of these updates is optional, but some are required because, for instance, the platform supplier no longer provides support for older versions.
These platform changes always result in development-related costs, even if it is