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)
