Paying Technical Debt

There seems to be a lot of talk lately about paying down technical debt. Some talk about how after the debt has built up enough it would be best to just scrap the system and rewrite. Some talk about how rewriting is never the solution. Others talk about using this debt as a tool. Many don’t want to see any of this debt in their code.

All Code Incurs Debt

All code at some point will incur tech debt. The framework it is built on has updates. The programming language has updates. Popularity of this third-party framework falls, and it becomes unmaintained. Security vulnerabilities are found. Incurring technical debt is unavoidable.

You can make choices around what type of debt to incur. You can choose where to incur this debt. Debt around how the code looks can be avoided with static code analysis. This can eliminate certain categories of potential future debt. However, you still incur a cost for this. Perhaps a license fee for the tool, but definitely time in the build, and developer time to fix issues. We can look at this as a small, short-term loan. It is repaid quickly, and the interest charged is very small. We pay this because on the other hand, when a bug goes unnoticed for a long period of time, the interest charged can become very great.

Paying Down Debt

We tend to look for times that we can use explicitly for paying down technical debt. We ask for bug fix sprints. Sometimes we can even get whole swaths of time devoted to upgrading this or that. Teams transition to “stabilization” or “performance” efforts. We are so disgusted at the amount of debt in our system that we want to just throw it away and start over.

As an industry we seem to go through huge swings of adding features, and then turning around and working on tech debt. Then back to features for a while. Then back to fixing, and so on. These swings are large and disruptive. Over time, the amplitude of these swings only increases.

We should instead focus on decreasing the amplitude of these swings. Clean the code as you work on it. Choose the “right” way to implement the new thing, rather than the “dirty” way. Take small steps, rather than not taking any steps, and hoping for a chance to take a giant leap sometime in the future.

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.