Today, I came across the idea (probably via stackoverflow) of technical debt. To quote Martin Fowler:

You have a piece of functionality that you need to add to your system. You see two ways to do it, one is quick to do but is messy – you are sure that it will make further changes harder in the future. The other results in a cleaner design, but will take longer to put in place.

Technical Debt is a wonderful metaphor developed by Ward Cunningham to help us think about this problem.

As is my wont, I immediately saw how this problem is not confined to the world of software (and web) development, but really to any project at all that has an element of iteration to it.

For example, consider making a table.  You really need this table fast, so you don’t spend as much time putting it together as you could.  Maybe you don’t let the glue set long enough or you don’t countersink the wood screws.  Whatever the shortcut, shortcuts have consequences.  Your table might not last long or put up with continued use.

To go even further, away from the arena of “making stuff”, think about a relationship in your life where many initial missteps were made that were not vetted at the time.  Those missteps almost always come back to haunt you once the relationship is tested, even if that test is just the passing of time.

Now, as many have pointed out, sometimes the debt is necessary.  Martin Fowler again:

The metaphor also explains why it may be sensible to do the quick and dirty approach. Just as a business incurs some debt to take advantage of a market opportunity developers may incur technical debt to hit an important deadline.

So how can we get better at knowing the difference between the debt black hole and the debt that confers an advantage?  Which messes are worth making?  I’ve been thinking of some criteria:

• Have I encountered this situation in the past, and the debt just wasn’t worth it?  This is seemingly obvious, but oftentimes I find myself glossing over how bad it was last time.  It’s better to really get inside of how frustrating the shortcut ultimately was.
  
• Does it just keep bothering me?  This sounds vague, but I think all of us know what it’s like to have a decision or conflict or debt that gnaws at our minds.
• Will it possibly be the ruin of my project?  This is heavy, but needs to be asked, point-blank, at key decision times.  Sometimes we don’t want to believe something seemingly so small (and so helpful!) could undermine everything, especially if the alternative route is painful in any way.  Interestingly, many times I’ve confronted this metric only to realize that I actually didn’t care if the project destroyed itself. Which made me realize I was spending my time on the wrong project!