- Technical debt
-
Technical debt (also known as design debt or code debt) are synonymous, neologistic metaphors referring to the eventual consequences of poor software architecture and software development within a codebase.
Common causes of technical debt include (a combination of):
- Business pressures, where the business considers getting something released sooner is of more value than avoiding technical debt
- Lack of process or understanding, where businesses are blind to the concept of technical debt, and make decisions without considering the implications
- Lack of building loosely coupled components, where functions are hard-coded; when business needs change, the software is inflexible.
- Lack of documentation, where code is created, but may be difficult or time consuming for anyone other than the author to understand, as functions are not documented
"Interest payments" are both in the necessary local maintenance and the absence of maintenance by other users of the project. Ongoing development in the upstream project can increase the cost of "paying off the debt" in the future.
Best Practice in paying down technical debt is to refactor code as part of ongoing development.
"As an evolving program is continually changed, its complexity, reflecting deteriorating structure, increases unless work is done to maintain or reduce it."
— Meir Manny Lehman, 1980
While Manny Lehman's Law already indicated that evolving programs continually add to their complexity and deteriorating structure unless work is done to maintain it, Ward Cunningham first drew the comparison between technical complexity and debt in a 1992 experience report:
- 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. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.[1]
In his influential 2004 text, Refactoring to Patterns, Joshua Kerievsky presents a comparable argument concerning the costs associated with architectural negligence, which he describes as "design debt".[2]
Activities that might be postponed include documentation, writing tests, attending to TODO comments and tackling compiler and static code analysis warnings. Other instances of technical debt include knowledge that isn't shared around the organization and code that is too confusing to be modified easily.
In open-source software, postponing sending local changes to the upstream project is a technical debt.
References
- ^ Ward Cunningham (1992-03-26). "The WyCash Portfolio Management System". http://c2.com/doc/oopsla92.html. Retrieved 2008-09-26.
- ^ Kerievsky, Joshua (2004). Refactoring to Patterns. ISBN 0321213351.
See also
External links
- Ward explains what debt metaphor is from youtube(video) and C2.com(transcript)
- Steve McConnell discusses Technical Debt
- TechnicalDebt from MF Bliki
- Andy Lester's talk on "Getting out of technical debt"
- Pay off technical debt with Code Offsets
- [1] Lehmans law
Categories:- Metaphors
- Software architecture
- Software engineering terminology
- Software maintenance
Wikimedia Foundation. 2010.