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…