A Pragmatic Approach to Manage Technical Debt Efficiently

Managing tech debt can be a real challenge, within a team of engineers. Here are a few ways to think about tech debt without ever being overwhelmed by it.

1) Assessing the tech debt

It can be useful to identify and be transparent about the areas of the codebase that need optimizing/refactoring. Not only does it help engineers scope the problem, but it also allows product managers to understand better the timelines, based on whether a “quick & dirty” solution is used or a cleaner implementation.

2) Understanding the tradeoffs

Tech debt can become quite a divisive issue. On the one hand, addressing it ensures the long-term health and stability of the codebase. It also helps with readability, which proves to be particularly helpful when onboarding new engineers and sharing internal knowledge. On the other hand, it can be time-consuming and can even introduce new bugs.

3) Beyond the tradeoffs: the North Star

Hence the need to make an informed decision based on how impactful such a refactoring would be. I’ll take the extreme example of an early-stage startup, that typically has a few months to a couple of years of runway. In such an environment, the ultimate goal is to survive and become profitable. So why would you spend some of that precious time refactoring code? As the saying goes: “If it ain’t broke, don’t fix it.” In other words: if a piece of code is already working properly, it’s probably best to leave it as is, instead of refactoring it without a clear purpose. That being said, if addressing some tech debt unlocks a new feature that directly benefits the UX of your customers, then it becomes reasonable to do so!

If your team agrees on what your North Star is, then you can objectively weigh the pros & cons and make a call!