What to take into account when choosing between technical debt and new features

Problem

It's no secret that code is like clothes. As you build new functionalities on top of it, it wears off. It's also no secret that, as code wears off, technical debt accumulates. The problem with accumulating technical debt is that it makes it difficult to build new functionalities. Sometimes, this is to the point where it simply breaks the whole system. That's why it's so important to manage your technical debt. The tricky part, however, is when to do so. One of the teams I supported a few years ago once experienced this crucial moment. On the one hand, the team owned a mission-critical system that needed to survive the foreseeable traffic surge that was projected to double in the following six months. On the other hand, the team was also supposed to play an important role in a strategically important big bet by building some features within a short period of time. Placing more engineers was out of the question, because the urgency didn't allow new engineers any time to ramp up. The only solution, as it turned out, was to optimize the existing engineers. Facing two obvious choices - managing technical debt or building new features, I bravely chose the third choice: both. Why not? I rationalized that we could always double the hardware to scale up the system horizontally, right?

Actions taken

We failed badly. We weren't able to achieve any of them. Remember that we expected to do both, not only building the new features but also removing the technical debt. But we ended up not doing either. The reality was that, as the system was handling more traffic, we started to identify new issues. This caused stability concerns that we didn't expect to happen. We had to pull people away from their work to improve stability. As patches were made on top of the system, technical debt increased, which caused more issues to appear. What's worse, some of the patches were made in a rush so that they didn't scale well. As the incoming traffic increased, these patches started to cause scalability concerns. Very soon, this downward spiral forced the entire team to pause their work and instead focus on the fire. The team became reactive rather than proactive: it barely addressed the issues that came up, and was unable to prevent the issues from happening in the first place. What we ended up with was a system with more technical debt and a set of half-baked features. If we had focused on only one of them, we would have been in a much better place.

Lessons learned

You should never underestimate the impact of technical debt. The impact is negative and often at a much larger scale than you expect. Managing technical debt should be both important and urgent on your list. Prioritize it, unless you are absolutely sure about what you are doing. When making a choice, people are extremely bad at predicting the outcomes. This is particularly true when the choice involves technical debt, which is less attractive to work on. It's also more difficult to perceive the pains that technical debt can cause. It's like managing your own financial investment. If you inherit a small fortune, would you pay off your student loan or would you buy a luxury car? It's easy to choose the latter, because it makes you feel better to assume that you would inherit another fortune some time soon. Whenever you think this way, stop and make sure it's absolutely what you want to do. Of course, sometimes, it can make more sense to invest in building new features while putting technical debt in the back seat. One example is when you have to be opportunistic on a business-threatening bet. For example, if you don't ship a feature you'll go out of business. Choosing technical debt will only mean you do well on unimportant tasks. Choosing new features will at least give you a chance to do something important to an okay standard. Survival is always the first need. At the end of the day, there is no silver bullet. It all boils down to the specific situation you are in.