Notes for KWRuby February 2016: Technical Debt

Declan Whelan presented to KWRuby meeting on February 17. He spoke about how to deal with technical debt in agile software projects:


  • old code bases tend to have lots of debt which slows down development
  • Martin Fowler described the tech debt quadrants (i.e., deliberate vs inadvertent, reckless vs prudent)
  • the term was originally coined by Ward Cunningham when describing technical trade-offs to the financial people on a project
  • Declan's definition is: anything in the code that slows me down
  • code which does not map well to the problem domain
  • badly written code, however, should not be considered technical debt (e.g., not tests, not TDD, not SOLID
  • Simon pointed out that technical debt can slow down paying feature debt, and that it can change as features change over time
  • Domain Driven Design(DDD) can help my continuously driving the code back towards the problem domain


  • there are various software metrics which can be used measure/estimate technical debt (e.g., various kinds of static analysis, churn analysis)
  • the Agile Alliance working from is trying to develop tools for analyzing finance and risk related to technical debt in a project
  • Garter wrote a technical debt report in 2010
    • estimated the global cost of technical debt was $500 billion, and expected it to rise to $1 trillion by 2015
  • a more informally definition could include
    • how happy are you in the code
    • what % of time is wasted
    • what would it take to fix

Dealing with it

  • increasing tech debt will increase the desire for a re-write and it is well establish that a re-write can be VERY risky
    • this is something that Declan has seen in large companies
  • it is a deeper problem than "our developers write crappy code"
  • What are the underlying reasons?
  • over time is gets hard to do fundamental fixes
    • this gets worse unless there is specific push back on this
  • our cognitive bias of recency bias, leads us to short term/fast solutions
    • one strategy is to not offer short term/faster options to client, because they will always chooser faster
  • forward looking leaders are important to choosing slower but longer term solutions
  • legal liability may eventually apply some pressure
    • Uncle Bob had discussed this before
    • Declan did an interviewed with [Martin Fowler] and Uncle Bob at Remote Agile Conference
    • maybe some big catastrophic event will precipitate this
  • avoid short term project which build on underlying products
    • this encourages the short term choices
    • instead align team/projects to maintaining the products over the long term
  • Test Driven Developer(TDD) is a useful tool for guiding your code towards the better long term choices
  • [Scrum]( has been a problem because is frequently adopted as a management practise without also adopting a corresponding technical process (i.e., Agile engineering practices, XP) such as:

  • some suggestions from the audience for helping with technical debt

    • business agreement
    • static analysis
    • explicitly organized dealing with technical debt with epics, sprints, or chore stories
    • education