I work in a financial company, so this analogy is especially poignant to those I work with.

We all know – or hopefully should know – the risks associated with being in financial debt.  At times, it makes sense to go into a little debt to buy something we can’t yet afford out of pocket (like a house or a car).  If we get into too much debt though, we end up paying all of our money in interest and don’t have enough to pay down the principal. Eventually, we may default or go bankrupt.

The same idea can be applied within IT.  Ward Cunningham coined the term Technical Debt to refer to instances where a developer chooses a poor design over a more well-crafted, sometimes “more expensive” design (in terms of time and/or effort).  At times this make sense – such as if we want to get something out to production sooner to take advantage of new features.

• Larger maintenance effort
• More difficulty in building upon the initial design
• Having to perform manual operations that could have been automated.

It’s important to identify these risks and be sure to pay down the “principal” (through refactoring and re-designs) over time so that we don’t bury ourselves in too much of our own technical debt.  And, just like when paying down financial debt, it’s ok to pay down a little at a time (through small design changes/refactorings) instead of trying to make one big “payment”.

Think about any projects or systems you have on your team.  Are you incurring any technical debt from those systems?  Is that “interest” hindering your daily activities?  In what ways could you try to pay down that debt today, if you had the time?

Some food for thought…