Understanding and Managing Technical Debt in Software Development
Technical Debt
Ward Cunningham first drew the comparison between technical complexity and debt in 1992. Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt.
Extending the Metaphor
Steve McConnell: Technical debt includes both intentional and unintentional violations of good architectural and coding practice. This expands Cunningham’s original focus on intentional decisions to release suboptimal code to achieve objectives such as faster delivery.
Doing the System Right
Technical debt is about doing the system right, not about doing the right system.
- It doesn’t address functional completeness.
- It does not predict market success.
To find your current level of technical debt:
- Start with code analysis.
- Look at quality deficits.
- Determine the time to fix per deficit.
- Aggregate the time to fix.
- Aggregate the cost to fix.
Monetizing Technical Debt
Once you monetize technical debt, any stakeholder can appreciate its operational, financial, and business implications.
I. Gat: A good debt is one we carefully use to evolve our products, make money, grow our business, and pay our debt back. A bad debt includes expenses that are wasteful and doesn’t include plans for how to pay it back within a reasonable time.
C. Ebert: Technical Debt Definitions:
- Should-fix violations are violations of good architectural or coding practice known to have an unacceptable probability of contributing to severe operational problems or to high costs of ownership.
- Principal is the cost of remediating should-fix violations in production code.
- Interest is the continuing costs attributable to should-fix violations in production code that haven’t been remediated, such as greater maintenance hours and inefficient resource usage.
- Technical debt is the future costs attributable to known violations in production code that should be fixed – a cost that includes both principal and interest.
The Trade-Off
Most definitions of technical debt come down to a trade-off between quality, time, and cost.
- Intentional decisions to trade off competing concerns during development.
- Negative effects tend to be longer term – increased complexity, poor performance, low maintainability, and fragile code.
As long as a project properly manages technical debt, it can achieve selected goals sooner than would have otherwise been possible. E. Lim, N. Taksande, and C. Seaman.
Estimating Technical Debt
A function of three variables:
- Number of should-fix violations in an application.
- Hours to fix each violation.
- Cost of labor. B. Curtis, J. Sappidi, A. Szynkarski.
Three estimates with different parameters:
- High, medium, and low severity violations.
- US $70-$80 per hour.
- 700 applications, 357 MLOC, all larger than 10KLOC, many different industries (bias toward business-critical applications).
Tool Support
CAST’s Application Intelligence Platform (AIP) – Curtis, 2012. Uses more than 1200 rules to detect violations of good architectural and coding practice.
Quality Characteristics for Technical Debt
- Robustness – stability or resilience of an application and its ability to avoid outages or recover quickly from them.
- Performance efficiency – application’s responsiveness and its efficient use of resources.
- Security – an application’s ability to prevent unauthorized intrusions and protect confidential information.
- Transferability – ease with which a new team can understand the application and quickly become productive in working with it.
- Changeability – an application’s ability to be easily modified and avoid the injection of new defects.
AIP evaluates from 176 to 506 rules for each quality characteristic, and some rules are evaluated for more than one characteristic.
Themes for Violations
The number of violations per application is large for all the applications.
- The average number of violations in Java EE for the high-severity violation of using fields from other classes was 1,173 per application.
A consistent problem was:
- A module-calling structure with high fan-out to external components.
- A control flow with high internal complexity.
Changeability and transferability violations were frequently complexity related as well as violations of practices that aid comprehension.
The Impact of Technical Debt
A conservative estimate of the technical debt principal for the average application is $361,000 for each 100 KLOC. More realistic estimates are likely to be dismissed as excessive.