Technical Debt, Technical Interest, and Technical Vigorish

When was the last time you heard the term "technical debt?"  If you're a developer, it was probably pretty recently.  Now when was the last time you heard the term "technical interest?"  I bet it has been significantly longer.  Ward Cunningham, who coined the term "technical debt," was definitely thinking about the interest angle: "Every minute spent on not-quite-right code," he wrote, "counts as interest on that debt."  But I think a lot of developers and shops today aren't thinking about technical interest as a consequence of technical debt.  They treat technical debt as a casual interest-free loan from friends or family--a "debt" that may never even come due.  I think this attitude towards technical debt is a mistake.  I think that we not only pay interest on our technical debt--we often pay vigorish.

"Vigorish" is the unreasonably high and often compound interest that a loan shark charges.  It goes up at the shark's whim and is often so high that realistically the debt cannot be repaid.  How does vigorish apply to code?  Let's say you write a "quick hack" to do X.  The effort to fix that hack at some point represents your technical debt.  Now an experienced developer spends an hour tracking down a bug attributable to bad assumptions around your hack--that's some of your technical interest.  Now a new developer in your shop needs to do X as well and finds your hack in the code.  From that moment on, until the new developer is corrected, he will replicate your hack every time he needs to do X.  He thinks your hack is the "right way" to do X, or at least an acceptable one.  Future developers will then have even more examples of your "quick hack" to find and copy themselves, further spreading the influence of your "quick hack" in potentially exponential fashion.  And that's technical vigorish.

Recently I've been trying to adjust my approach to technical debt in order to avoid technical interest in general and technical vigorish in particular.  Here are some of the better practices I've been attempting:

• Treat technical debt as debt.  Have a very good sense of how much there is in a given project, and a timeline for paying it back, just as if I were managing a "financial debt."  This works pretty well in scrum, by the way.
• When I do have to incur technical debt, try to isolate it.  Prefer debt in implementations to debt in APIs / interfaces, which, being more public, tend to generate more interest and vigorish.
• Comment conspicuously on patterns that should not be emulated, ideally explaining the "right way" and why I didn't do it.
• Keep technical debt out of key infrastructure and processes that I depend on day to day.  By some trick of developer psychology it seems we're most tolerant of technical debt in the tools and processes we use all the time--like building and deploying--even though these generate lots of interest and vigorish very quickly.
• Submit code for peer review.  This practice has made possibly the biggest impact for me.  I work with sharp folks, and they sometimes see ways to do something that are both better and cheaper than anything I've come up with.  Review also helps catch fossilized bad habits, somewhat offsetting technical vigorish.  Finally, the shame of bringing bad code to the attention of folks I respect often inspires me to bite the bullet and pay down my code's technical debt before I even commit it in the first place.