Why You Need to Take Technical Debt into Account
Luke Hohmann, founder and CEO of The Innovation Games Company, recently commented on Twitter that he was saddened by the trendiness of technical debt. The conversation that followed led me to think a bit more deeply about technical debt—when it is a useful concept and when it’s not.
Technical debt is a metaphor for the result of skipping design or implementation steps in order to achieve a short-term goal. The next time you work with the code, remember that changes may be more costly to make because of your prior decisions. You achieved something, but you incurred debt.
The concept of technical debt can provide a framework for discussing tradeoffs when deciding on an approach to making a change in your code. Some say that sloppy work is not technical debt; it’s just sloppy work. Others have suggested that there are various kinds of technical debt and that any decision that leads to poor design can be considered technical debt. People with this viewpoint believe that there is a better distinction between prudent and reckless debt.
Technical debt, like financial debt, becomes problematic when you think about it as inevitable and incur it without considering the cost of a decision or monitoring your debt load. While a mortgage is a more thought-out debt to undertake than credit-card debt, either can get you into trouble.
Technical debt can be unavoidable, and it’s important to take time to pay it down. If you let the debt accumulate too much, you may end up in deep trouble.
Like financial debt, it’s important to be aware of when you are incurring debt, or if that fails, be aware of the cost of the debts you have accrued and think about a payment plan. Any costs that you incur to pay down technical debt need to be a part of your prioritization in the same way that you take into account the return on investment (ROI). Also, consider the role of technical debt in your project portfolio vision.
It’s useful to have a name for the costs associated with the design and implementation decisions that you considered “bad,” either initially or in retrospect. Keep in mind, however, that having an official-sounding name for these costs does not mean that it’s acceptable to be thoughtless.
While saying “I’m incurring technical debt” sounds better than “I hacked this together quickly,” you should not take the more polite way of expressing the same sentiment as an excuse. If the metaphor helps you form a model for evaluating costs, then it’s useful. But be aware of situations where technical debt becomes more of an excuse than a metaphor.
Do you use the term technical debt on your team? When you discuss it, do you discuss the costs?
