Research on managing Technical Debt

Summary

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.

Objectives:

• 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)