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.
