Technical Debt: What is it? and, How to quantify and manage it?
Background:
With CIOs estimating that Technical Debt amounts to 20–40% of the value of their entire Technology estate before depreciation and with over 60% of CIOs believing that organisation’s technical debt is increasing3 this is not a topic to be ignored.
Definition:
There are 2 perspectives to understand ‘Technical Debt’.
From a technical perspective, it refers to the accumulated costs of using poor coding techniques, delaying routine maintenance, making quality/time trade-offs, and employing other suboptimal IT practices in the enterprise. While quick fixes may lower costs in the short term or keep projects on schedule, but they can also cause serious problems down the road if left unaddressed. Specifically, they may lead to outages, security vulnerabilities, and increased maintenance costs.1 As per the diagram to the left, it is important to recognise that Technical Debt can arise from any part of the IT Functional Stack.
From a financial perspective, Technical Debt is an off-balance sheet (OBS) item. OBS items is a term for assets or liabilities that do not appear on a company’s balance sheet. Although not recorded on the balance sheet, OBS items are still assets and liabilities of the company as they are typically not owned by or are a direct obligation of the company. are an important concern for investors when assessing a company’s financial-health.2
How to quantify Technical Debt?
Like any financial debt, it is good to think of Technical Debt in terms of a ‘Principal’ and an ‘Interest’ component.3
- The ‘Principal’ is all the work that must be done to modernise the entire technology stack. This includes deferred maintenance or upgrades and modifications.
- The ‘Interest’ is the complexity tax that every project pays. It derives from the need to work through fragile systems and creation of workarounds. Collectively, these harm current capital expenditure budgets and project RoI.
LayerFor 'Principle'For 'Interest'ApplicationThere are many tools that automate the identification of code related issues such as source code formatting, low test coverage, lack of modularity, code complexity, lack of documentation. Some of the tools listed below:
- Coverity, SonarQube, Checkstyle, Closure compiler
- Appropriate discount factors can be applied to this data once gathered.
Project Timesheets*InfrastructurePopular methods include
- End-of-Life / End-of-Support dates (for all 3rd party infrastructure products covering Network, server, os, security software, etc)
Project Timesheets*Processtbdtbd
* subject to availability of necessary detail
Recommendations to manage Technical Debt
- Create a shared definition: Finance, Business & IT Leaders need to agree up on a shared definition of what constitutes IT Debt so it can be tracked and measured.
- Create Measurable Transparency: Technical Debt to be added to the Total Cost of Ownership (TCO) and Unit Cost metrics as a comprehensive measure of understanding the overall cost.
- Create joint ownership mechanisms to reduce it: Assign ownership of Technical Debt down to the P&L level (ie the ‘Interest’ component) for the Business Unit or Product consuming the system(s).
1 Wall Street Journal – How to Calculate Technical Debt
2 Investopedia – Off-Balance Sheet (OBS) items
3 McKinsey Digital – Tech debt: Reclaiming tech equity
4 https://dzone.com/articles/what-technical-debt-it-and-how-to-calculate-it
