The Only Way To Control Technical Debt At a Sustainable Level
Many startups have out of control tech debt. I have seen repeated outages, dissatisfied customers, customers threatening to sue, not being able to accommodate prospects with a high traffic, an ongoing loss of productivity caused by tech debt, dissatisfaction in the engineering team, and more.
How can we prevent this from happening? By having a few rules:
First, if you’re working on something and run into tech debt, fix it. For example, if you’re modifying a class to add a feature, and you’re stopped in your tracks because the class is poorly structured or undocumented or buggy, stop your feature work and fix the class. Create a new Git workspace1 , refactor the class, merge it into master, pull the changes into your older workspace, and resume the original task.
Second, treat resolving tech debt as part of the task, not a separate task onto itself to be done some day. If you want to be healthy, you need to consider health as a factor in your day to day decision making, like whether to meet at a park or a restaurant. You can’t put “health” into a box and say you’ll work on it separately. Similarly, you should have a working style that over time reduces tech debt. Just consider it a part of work like reviewing code, merging it or attending team meetings is. If building a feature is supposed to take 40 hours, but takes 100, accept it, because those 60 extra hours will save you 120 over time 2. Don’t be myopic and ask if those 60 hours spent are worth it for this task. For example, going for a walk is good for your health, even if it doesn’t result in a benefit today.
Third, if you’re not sure whether the tech debt you’ve run into is contributing to the problem, fix it anyway. For example, say your RabbitMQ server keeps running out of memory and crashing. As you investigate it, you find that you’re running a version of RabbitMQ past its end of life. Upgrade it! Don’t overthink it. If it alleviates the memory problem, good. If not, you’ve resolved some technical debt, which is good, too. Over-planning this is time wasted: if it takes 10 hours to upgrade RabbitMQ and 1 hour to analyse whether you should, you’ve spent 11 hours rather than 10.
Fourth, don’t dig up and fix every line of code. We don’t have the time for that. Fix problems that present themselves 3.
Or branch.
If you’re making good decisions about what and how to fix.
This also prevent over-engineering and solving problems that don’t exist, like putting in a factory for each class, whether or not one is needed.