All Collections
Technical Debt
Technical Debt
Gabriele Gallo Stampino avatar
Written by Gabriele Gallo Stampino
Updated over a week ago

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.


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


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



Low (Recommended)

6% - 10%


11% - 20%


21% - 50%


51% or more


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

Learn more on this topic

Did this answer your question?