Debt, depreciation or risk?
When I first heard the phrase “Technical Debt”, I nearly fell of my chair, but recently, a couple of articles have reminded me together, with of course, the UK Track & Trace failure, and so I thought I’d have look and think about it again and see if it helps address the intractable problem of funding the maintenance of legacy technology. The problem is that to make changes, code in use requires change, which will increase the cost of the project. Wikipedia defines Technical Debt, as follow,
Technical debt … is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer.
This definition is limiting in two ways, firstly, it only relates to cost created by today’s design choices and secondly the definition is designed to be limited to software development projects. It is not easily applied to the whole maintenance problem, which includes platform & package upgrades, the development of incremental functionality and bug fixes.
Not only is the problem that Technical Debt seeks to address limited, but it’s also basically a metaphor. Identifying the value of the principal is very hard and financial management tools available via the concept of debt don’t improve the understanding of the problem.
I suggest that depreciation is a more useful analytical framework as are risk management techniques, but the issue remains, within a distributed budget, “Who pays?”. This is important because without an accurate allocation of costs, return on investment cannot be properly calculated, and thus the decision to initiate a project may be taken on false information.
Depreciation would seem to be a critical concept in the cost model of software ownership. Software depreciates due to external factors i.e. the state of the technology market and changing business needs and software depreciation causes a current account expense i.e. the maintenance budget.
The concept of Technical Debt may help identify future costs in today’s development budget incurred because of what you already have, particularly constraints caused by other projects. The quadrant, I believe publicised by Martin Fowler, plots planning approach vs risk appetite, shows a classified model of the sources of technical debt, what it does not include is that all software, even the most tested, will have errors in it and so they will be discovered at some time in the future. The best reason suggested in the quadrant is that a conscious compromise has been made to meet other goals, usually of time to deliver or cost through the minimisation of effort or the use of cheaper resources, as in the case of the NHS Track & Trace, where they used Excel as the visualisation tool[1]. Many of these costs can be identified and the expense forecast, and if so approved by the SDLC and the Enterprise Architecture governance processes.
An alternative tool for identifying future maintenance costs would be to use risk management techniques. One principle of risk management is that risks should be consciously accepted or mitigated; the problem with the initiation of much technical debt would seem to be that this does not occur i.e. the conscious acceptance does not occur. The reason that risk analysis is useful is that a risk is a cost that may occur sometime in the future; its likelihood and cost should be estimated, a risk classification assigned, and remediation planned. The sum of one’s planned remediation costs then becomes the “technical debt interest” payments, without evaluating a principal.
My conclusion is that Technical Debt is not such a useful concept, and that applying standard risk management analysis is a more effective means of planning a maintenance budget which should consist of funding for both error & risk remediation.
[1]The problem was that it was too old, 32 bit and required the whole data set to be enclosed in the excel runtime image. The decision to use the old version was probably taken unconsciously or by adopting a customer standard.
Originally published in Nov 2020 at https://www.linkedin.com.