The Technical Debt Trap
Ward CunninghamI run the risk of looking like a Cunningham Fanboy with this presentation. I effectively stand in front of the audience and say, "Ward Cunningham says..." I don't know Ward personally, but I wouldn't mind meeting him some day. His insights on the development process and our responsibilities as developers are keen, his message is clear, and it is way easier to appeal to authority than to convince people to listen to me.
ReferencesThere are a number of references in this slide deck. I've included all of the links along with a brief explanation of each.
OOPSLA '92 Experience Report
Ward Cunningham's brief on the WyCash Portfolio Management System wherein he likens shipping first time code to going into debt and warns of the potential pitfalls.
James Shore on Voluntary Technical Debt
James talks about how a savvy team can use technical debt as a tool to accomplish more than they otherwise would.
David Laribee on Paying Back Technical Debt
David discusses the burden of Technical Debt on a project team and the use of agile practices to pay the debt down.
Steve McConnell on Technical Debt
Steve focuses on an approach to technical debt from a business perspective, looking at decisions to incur debt, how to ensure it is the right kind of debt, and how to service the debt.
Martin Fowler expands the Metaphor
Martin has several entries on Technical Debt. In this particular entry, Martin refers to Ward's definition of technical debt and provides a condensed definition that I believe could be the most often referred to definition.
Ward's Video Statement
Ward creates a video wherein he discusses the technical debt metaphor and explains his views on messy code as it applies to technical debt.
Ward Tweets about Technical Debt
Dirty code is to technical debt as the pawn broker is to financial debt. Don't think you are ever going to get your code back.
Continuous Refactoring and ROI
The team over at Software Management Blog explain how to use continuous refactoring to keep your technical debt down and shows the flaw in scheduling refactoring into large concentrated efforts.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)