The Technical Debt Trap

I had the honor of presenting at Chicago Code Camp this week on the topic of technical debt. For those of you who know me, you know this is a topic I feel passionately about. More accurately, I am concerned about the misunderstandings surrounding technical debt and the frequent use of the term to placate any sense of responsibility over writing messy code in pursuit of a deadline.

Ward Cunningham
I 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.

There 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.


  1. Enjoyed your slides, thanks!

    The comment from Ward Cunningham on "The ability to pay back debt... depends upon you writing code that is clean enough to be able to refactor..." really sums things up for me.

    I personally think there's even deeper repercussions, as I wrote here:

  2. I LOVE this. Too often I have heard technical debt being used as a synonym for crappy code. As if "we can go clean it up later". In the same vein, I've seen Agile being used as an excuse for not doing any analysis whatsoever.

    You know what I mean. When you get the "user story" that should read like Pride and Prejudice but instead looks like a message on twitter. It's like people think that because they can "summarize" it in one sentence that it somehow makes the implementation trivial.