Technical Debt

Ward Cunningham first coined the term “Technical Debt” and used a financial metaphor to explain the impact of deferred work as a result of rushed and messy development practices to deliver new features quickly, rather than having sufficient time to build those features with appropriate time to refine the design.

Technical debt is like credit card debt. The credit card can be used to pay for new features, with each purchase incurring a small amount of debt. Just like credit card debt, it can be paid off in small instalments or all at once, but it will have to be paid off or otherwise that will lead to high interest payments. The longer we leave payment, the more debt we can accrue with compounding interest.

The more technical debt that is accrued, the decrease in the cost effectiveness of a team’s ability to deliver new features, until such a point that it becomes uneconomic to add any new functionality and the team suggest a complete rewrite.

In this worst case scenario, the team are spending more time trying to figure out how to integrate a new feature into the layers of workarounds, superficial fixes and compromised code design rather than building the feature itself.

A compromised system riddled with technical debt can also be a brittle one, where adding a new feature yields surprising defects in other parts of the system, which when fixed can then also raise additional responding defects in the system. The nightmare scenario is where there is no end to the defects and subsequent fixes that introduce even more technical debt, which yields more defects and so on until the economic collapse of the project.

The origins of technical debt can be wide ranging and include sources such as:

• Prototype code that was intended to be temporary, but has not been removed from the code base
• Redundant code that has not been refactored or removed from the code base
• Rapid feature development that works in isolation, but impacts the wider design and code base
• Focussing on progress and new features rather than also focussing on the health of the code base
• Superficial workarounds rather than spending time to refine the design and provide good fixes to the underlying issues

Paying off the Technical Debt can be done in several ways such as:

• Debt avoidance through the use of Test First Development techniques that prevent defects from happening rather than defect detection techniques after the code has been written
• Continuous Integration techniques that provide regular feedback on the integration of the code and the health of the code base as the code is written
• Continual Refactoring of the code and the design to ensure that the latest feature not only works well, but is also cohesive within the larger product, the design and sits seamlessly with the other code components in the product
• Prioritising architectural work with the same importance as new features ensures that the codebase behind the scenes is just as important as the new shiny button on the user interface
• Shared Code policies in a team to encourage them to fix and refine issues as soon as they are discovered in the code base
• Energized Work to introduce a sustainable working pace that invests for the long term and has sufficient time to remove technical debt as new features are built
• Pair Programming that encourages multiple developers to collaborate when building new features and detect and eradicate technical debt as it appears

Tactical Fast Delivery

Taking a tactical short-term approach to deliver more features has the benefits of faster time to market, which may be useful to capture new market share, but also compromises the longer term health of the code base from the technical debt introduced.

Strategic Provision For The Future

Taking a strategic long-term view of the product may require more time to introduce new features and refine the design sufficiently to preserve the integrity of the code base and remove any technical debt introduced, however, the investment pays off with improved efficiency to introduce future features in the long run.

Hence, a balanced and considered approach may be needed when handling Technical Debt depending on the needs of the project and the economic situation.

See Also

• Feature Debt

References

1. Technical Debt, Fowler M, accessed 03 January 2018
2. Introduction To The Technical Debt Concept accessed 03 January 2018
3. Technical Debt accessed 03 January 2018