Technical debt is not as bad as you think

I’ve seen software engineers complain and despair about technical debt, but the truth is that technical debt is not as bad as you think. What’s important is knowing when to take action.

First, if you have technical debt, congratulations. It means that you have made the right trade-offs for the success of your business to get you this far. Because yes, good trade-offs that make it faster or more likely to close a deal, especially in the early stages, can make the difference between life and death for a startup.

Second, not all technical debt is the same, and what some software engineers will complain about as technical debt may simply be unfamiliarity with a new codebase. A few years ago, a software engineer joined our team and quickly complained about our framework, which they said was legacy and a ball of technical debt.

I was honestly surprised, yes it was no longer a greenfield project and it had been running for a couple of years, but the code was well organized, well maintained and more importantly we were able to make changes or add features to the codebase quickly without major hurdles. It took me a while to really understand that the challenge this particular engineer was referring to was his unfamiliarity with the codebase, and thus, for him, its complexity and inherent technical debt. As it turned out, 4 years later, that codebase was still alive and serving us well.

I talk about this because it is the main trap many of us fall into when we talk about technical debt. Often it’s due to unfamiliarity, and that’s unfortunately why new engineers landing on an existing project often have the urge to rewrite parts, if not all, of it.

I am not saying that technical debt does not exist and should always be ignored, there are many cases where major improvements to the codebase are needed, or maybe even a rewrite. The key is to recognize when this is the case: Are you still productive with this codebase? How long does it take to make a simple change? Can you easily extend the feature set and ship it without reliability concerns?

The next time you’re tempted to cite technical debt, stop and ask yourself these questions to make sure it’s really worth addressing at this point in time.