Managing your Software Debt

Software debt appears in several forms. The page treats technical debt as the most familiar case, but it also adds competence debt and quality debt. It says these debts raise maintenance costs, depress developers, and can make organizations think about replacing a system.

Reading notes

#

• Competence debt is the gap between what is in the codebase and how much of it the team understands.
• Competence debt grows over time, and it grows faster when a codebase stops changing.
• Pair programming can reduce both technical debt and competence debt by widening the areas each team member knows.
• Refactoring also helps with competence debt because changing a system reveals whether it is truly understood.
• When too few original developers remain, teams may believe the old system is impossible to maintain.
• Separate maintenance teams can increase technical and competence debt when domain knowledge and project backstory are lost.
• Sloppy or confusing code can push developers away and lower reuse across the codebase.
• Quality debt measures the effort needed to fix defects that exist in a software product at a given time.
• Technical debt concerns internal quality, while quality debt concerns the external quality that users see and experience.
• Quality debt gets harder to pay down as it ages, and unresolved defects can make later fixes harder.
• Suggested practices include Definition of Done, BDD or automated acceptance testing, continuous integration, automated testing, and not tolerating broken windows.