You don’t (always) get to decide when you pay down technical debt

“[I]f you cut corners in the short term, you’re borrowing against the future maintainability of the software and that at some point, not unlike a credit card, you’ll pay down that debt by going back and fixing the hacky solutions that were put in place.” - Ben Lakey in this Programmers StackExchange answer.

The quote above is one of the best explanations for the term “technical debt” that I’ve run across. I like that it’s succinct, and I like it’s credit card analogy. Like credit card debt’s increasing minimum payments, loading up on technical debt will represent an ever-increasing drag on your productivity. This plays out in the “How does this work again? I wish we had docs,” and “Uh oh, we broke feature X when we added feature Y. I wish we had tests,” type of problems that you routinely run into if you are cutting corners.

But even worse than credit card debt (whose collectors will happily allow you to make minimum payments for the rest of your natural, impoverished life), you don’t always get to decide when and how much technical debt above the minimum you “pay down.” Once enough of it piles up, you run out of “minimum payment” options and the only paths forward are those involving heavy refactors, rewrites, retroactive test suite creation, retroactive documentation, etc. In other words, all things that take a long time.

And of course you’ll usually run into that situation right before a critical release deadline. Because the Universe is cold and indifferent to your plight.