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

Learn more on this topic

Did this answer your question?