Research on managing Technical Debt


Background: Technical Debt (TD) is what happens when the code does not reflect the teams current best understanding of the problem: The code becomes more difficult to understand and change than it could be. Small amounts of Technical Debt are a fact of life and hardly a problem. Large amounts of Technical Debt can slow development to near-standstill and kill the joy of software development.

  • What pains do real teams in various companies perceive in these respects?
  • What terms and concepts do teams use to think and talk about their TD situation?
  • How problematic do they perceive their situation to be?
  • Where and how is their perception of the TD situation incorrect? Why?
  • How do teams cope with simple, easy-to-repair TD? How with medium-scale TD that takes hours to repair? How with large-scale (e.g. architectural) TD?
  • What mindset is behind these approaches?
  • What team-level or organization-level forces constrain or distort the approaches or their execution?
  • Do the approaches appear to be balanced in terms of cost/benefit? Or are some kinds of debt addressed to much and others too little?
  • ...

Methods: (to be added)

Status: (to be added)
Topic revision: r1 - 11 Jun 2019, LutzPrechelt
  • Printable version of this topic (p) Printable version of this topic (p)