What is technical debt?
It feels natural to build simple solutions instead of complicated ones
We create technical debt when, in doing so, we leave behind a problem we’ll deal with later
The “Debt” Analogy
“Leaving problems for later” is like “borrowing money”.
“Rework/refactoring” is like “repaying the principal”.
“Slower development” is like “paying interest”.
Impact of technical debt
Technical debt impacts engineering teams and businesses in various ways.
Although technical debt directly affects engineering teams, it also has a clear business impact.
Effect | Why it happens | Primary business impact |
Reduced productivity | Building new features take longer as developers encounter issues they didn’t anticipate. | Higher time to market |
Lower maintainability | The cost of maintaining the application grows as more capacity is needed to deal with existing issues. | Increased development cost |
Stability and performance issues | End-users are affected by frequent issues and bugs. This impacts adoption and ROI. | Lower user adoption and ROI |
Burnout | Dealing with issues continuously for long periods of time frustrates developers and may lead to resignation. | Turnover rate |
How does Clayton calculate technical debt?
“Technical debt” is a broad term that comprises many categories of issues. Clayton focuses specifically on “Code”, “Configuration” and “Security” debt.
We use a metric called Technical Debt Ratio (TDR)
Cfix: is the estimated cost to fix all the issues identified in the application
Cdev: is the estimated cost to develop the application (from scratch)
Every policy active on your project contributes equally to this measurement
Additional metrics
Issues → number of open issues
Remediation effort → estimated time to fix any open issues
Defect density → number of open issues per thousand lines of code (KLOC)
Guidance for engineering teams
Build simple solutions and avoid premature optimisation.
Accept some deliberate, prudent technical debt (”we must ship now and deal with the consequences”)
Avoid reckless technical debt (”we don’t have time for design”)
Be wary of piling up too much technical debt:
Business stakeholders will always push for new features
The more debt you have:
the harder it is to build new features
the harder it is to pay it back
TDR Threshold | Guidance |
<5% | Low (Recommended) |
6% - 10% | Medium |
11% - 20% | High |
21% - 50% | Severe |
51% or more | Extreme |
Compounding effects of technical debt
Business stakeholders will always push for new features
Building features and components “on top” of problematic code
Losing knowledge around design choices due to turnover
Best practices
Be in control of your technical debt at all times
Update your policies to ensure critical issues are detected automatically
Use protection modes to ensure critical issues are stopped automatically
Track technical debt in your backlog
Maintain a Technical Debt Ratio below 5%
Pay back debt quickly and regularly