If you are a startup, then you should know that technical debt is normal. It’s a sign your team is moving fast developing new features. The smaller and younger your company is the more focused it should be on customer development and acquisition and revenue generation. Zero technical debt is a clear sign of incorrect focus in a startup where engineering gets more priority than customer development. If you focus on clean code at that stage, you’ll lose valuable resources on something that might not have a market fit at all in the end. So, the goal is to move fast enough and acquire some technical debt but to the point where your team can still handle it, or, so to say, pay the interest. But how do you know that your technical debt is too big?
1. Random performance issues no one can explain
We had a problem like that on a project that was in development for a couple years. Management was still searching for the right business model, so the development team was moving fast from feature to feature making shortcuts whenever possible. We are big fans of Elasticsearch, and most of the search functionality we’ve built was powered by it. The only problem was that index was growing too fast, and after some point, we started to have unexpected load spikes nobody, and nobody knew what could cause them.
While performance issues with Elasticsearch are quite common and we know how to treat them, the fact that we had to spend a few days to find the cause was a problem. Situations like that show that your development team is moving too fast to get a grasp on the whole system. It’s important to slow down a bit in that case and place more emphasis on testing and refactoring, or you will keep growing your tech debt at the same pace and making things worse.
2. New developers with significant experience need few months to get up to speed
Technical debt is not why startups fail. Or, that’s not the only reason for failure. But when your next hire brings no value for months, it can be a reason for failure. New developers need to get on board and learn new things like the roadmap, the product and its vision etc., that’s quite common. But most of the time is spent learning the architecture of the code. If it’s too complicated, they will have a hard time figuring it out. They will also be extra cautious about making changes for quite some time which will slow down everything even further.
That’s another sign you need to pay interest on your technical debt to keep it at the same level. I’ve seen many cases where management was unhappy about the pace of onboarding and overall feature development while not allowing developers to work on improving the codebase. Try to find a day or two during the week to sit down with the team, identify parts of the codebase that got out of hand and let developers fix things they find unbearable. This way you can make the least pleasant part of the work to be one of the most rewarding.
3. New features result in new bugs
Inexperienced managers often blame developers calling them unprofessional for introducing bugs. Sometimes that’s the case, for example, code written by junior developers should be reviewed and tested rigorously before being merged into the main codebase, but you should have known that when hiring them. When you see that the number of bugs reported goes up each time a new feature is rolled out it’s most likely a sign of fragile code.
Most likely you are rushing the process, and your dev team is not writing tests for the features implemented. That results in parts of the system breaking when something is changed in a seemingly unrelated area of the codebase. You update the signup process and all of your forms validation breaks because they depend on the same code. I’m sure you’ve seen something like that. At this point, you need to refactor the code and decouple different parts of the application where required. You also need automated tests in place to detect this type of bugs early.
Addressing technical debt is a business decision
A decision to address technical debt should be taken on a higher level than just the technical team. Technical debt is an organization problem in the first place so it should be discussed with the non-technical folks too and requires buy-in from them. After all, you won’t be delivering new features at the same rate you were before, so you need to convince them it’s required and manage their expectations.
Communication is the key. Even if it looks like the problem is purely technical but it’s not: it was the decision a whole team made to work on a tighter schedule and implement more features to test them with customers. There can be many reasons to that and important deadlines down the road, so you need to align the goals of the technical team with the product team.
Should you address the technical debt?
If you are an early stage startup and you don’t have real clients and revenue, then technical debt is probably not a problem. After all, this debt may never come due and addressing it early on would be another problem called premature optimization. You can become a clean code advocate a bit later when you’ll make money and have resources to address technical debt.
But if your startup survived a year or two, then you might see the signs I’ve listed above. It’s your call to make a choice — either refactor or keep on pushing. In real life, choices are more complicated than abstract either-or tradeoffs. You can spend a lot of time cleaning up the code for the app that will not exist in a year. Or you may onboard new enterprise customer next month that needs a lot of, and your technical debt will become an impediment for new feature development. The best approach is always focusing on improving areas that cause the biggest slowdown, that includes both technical areas and organizational processes.