Technical debt is the future maintenance and change cost created by short-term technical shortcuts. It accumulates when teams hardcode values, perform minimal checks, skip security or upgrade patches, or otherwise defer more durable solutions. Some debt is a reasonable way to move quickly, but it needs deliberate repayment before its cost produces outages, rework, or excessive complexity. section 9.6
Manage technical debt as an operational responsibility:
- Track known debt during code review, releases, and upgrades, then add it to the backlog even when automated analysis cannot detect the design problem. section 9.6
- Set repayment capacity according to organizational context; a suggested range is 10% to 30% of team output, with a rest period after every two or three sprints as one possible mechanism. section 9.6
- Measure what can be measured with code-quality tools such as SonarQube, while retaining human judgment for short-term fixes that are syntactically valid but too narrow. section 9.6
- Avoid client-specific branches in shared code; prefer broadly valuable roadmap work, import or export paths, APIs, or plugin patterns that extend the system without changing its core. section 9.8
The client-specific shortcut
A conditional such as “if (Client == XYZ)” may satisfy one request quickly, but repeated client exceptions make the code harder to test and harder to change. A separate repository branch is worse: every enhancement and bug fix must be applied and tested across active branches, effectively doubling the workload. section 9.8
Use the figure to orient a repayment discussion around servicing technical debt rather than treating it as an invisible maintenance burden. section 9.6
