Balancing Technical Debt and Feature Development With Service Level Objectives

If we ask for a simple explanation of tech debt and the cause of it, generally, we hear something along the lines of: 

Tech debt is redoing or refactoring your team's work in a less-than-ideal way. 

Tech debt accumulates when you prioritize speed of delivery over the quality of the work, which can have significant consequences. However, you don't need to compromise quality over velocity with the help of Service Level Objectives (SLOs). 

Eliminating tech debt is impossible, so learning the best way to manage it relative to new development is the right mindset. It is no secret that the consequences of tech debt could be a poor user experience that leads to losing customers and increasing deployment costs, resulting in frustrated engineers. 

SLOs Can Help

Service Level Objectives are a way of strategizing your goals to achieve an ideal state where you have a reliable product that you created quickly. SLOs can be applied at every level of the tech stack to help teams to meet reliability goals and track their reliability standards across the organization. Technical debt can occur under many different circumstances. There are usually two categories of debt: one created consciously to meet a deadline, and the other made unknowingly due to stale code, lack of automation, or nested bugs. The critical point is that adopting SLO practices across your organization can catch and manage both types.

The Role of the Error Budget

SLOs have revolutionized reliability practices by allocating an error budget to each service level indicator (SLI) or metric. Error budgets provide you with the comfort of knowing that as long as you have adequate budget remaining, you do not have to worry about how your SLO is doing, and you can focus on developing new features. In this case, you know that your services are reliable since you have enough error budget and can spend time creating new features quickly. Once you get close to depleting your budget, you can shift your focus to ensuring you address the technical debt that may start causing reliability issues and slow down on deployment. This way, you don't need to constantly worry about tech debt while trying to focus on deployments. You get this buffer to focus solely on new features while you know you are still reliable. Adopting SLO practices places velocity and quality into equilibrium.

Example: How SLOs Help With Tech Debt

Let’s look at an example of how SLOs could better manage technical debt. In this example, a company is looking to optimize an existing workflow and customer journey through a website and improve the load time. Having SLOs on each workflow segment allows them to continuously deploy new changes to the website while monitoring the SLOs on the old segments. This setup ensures they have a sufficient error budget during their 7-day timeframe. By day five, they had completed ten deployments, and their error budget was now down to 10% due to some minor issues they safely ignored. The benefit of this practice is that each team gets to focus on deployment while monitoring technical debt using SLO and shift to addressing that debt once they get close to the error budget thresholds. At this point, they can focus on any minor issues and spend the next two days finding and remediating the root cause of technical debt. Relying on SLO in such a situation as above gives the organization the ability to entirely focus on deployment for five full days before they need to consider allocating resources to address any technical debt.

In conclusion, tech debt happens at every level, but you can minimize them by adopting good practices such as automation, coding standards, and company-wide SLO practices. With SLOs and error budgets, you can ignore technical debt during deployment until you get to a point where you need to shift focus on managing the debt.