Most engineering teams have a sense to some extent that technical debt is slowing them down. But just how much of an impact does technical debt have on teams? And what is the cause of most teams technical debt? We asked engineering teams around the world how they measure, approach, and mitigate tech debt to see how much it impacts them. And here are the high level results.

Want to contribute to the survey? Take 2 minutes to answer here

What does technical debt means?

Technical debt is a tricky thing to precisely define. We often hear tech debt being described by its symptoms - slower development, more confusing code, higher rates of bugs, frustrations building among a team, etc. The root causes are a blend of specific technical issues (antipatterns, architectural decesions, etc) and team cultural issues that contribute to how development is approached. Ultimately, the meaningful piece of tech debt is how much time or productivity we are losing to technical decisions (concious or not) that we previously made.

We saw a wide range of how much teams were slowed down by their technical debt. To simplify things, we split teams into three levels of tech debt - low, medium, and high. Low tech debt teams reported that technical debt was slowing down new projects by <30%. Medium tech debt teams were experiencing slowdowns of between 30 & 100% due to technical debt. High tech debt teams saw their development slow down by more than 100% because of their debt.

High tech debt cuts time spent on new development by ~40%

Technical debt plays a big role in determining how efficient an engineering team can be. Higher levels of debt shift how much time teams need to spend on bug fixes and managing legacy code vs how much time they can spend building new features.

In our survey, teams with medium to high levels of technical debt reported that they spend nearly 50% more time than low tech debt teams on bug fixing and understanding existing code and as a result spend nearly 40% less of their time working on developing new features. This trade off is consistent with what other studies on technical debt have found, with high tech debt teams always needing to spend more times on bugs and legacy code and less on new work.

Interestingly, low technical debt teams consistently reported that they spent more time in meetings and planning than medium/high technical debt teams. Whether or not this is causal is up for debate, but conceivably teams who have more of a focus on effective planning may wind up with a lower level of technical debt.

All teams experience some level of tech debt (and we need to be OK with that)

Nearly every team in the survey reported some form of slowdown in their development process because of the technical debt they faced (96% of all teams). This slowdown ranged from 5% at the low end to 200+% delays for high technical debt teams.

While a few responses reported that their teams encountered no technical debt (or at least no delays from technical debt), tech debt zero isn't necessarily what we should be striving for. Technical debt will naturally build up throughout the development process. We're always making guesses about what the future will look like when we're making our code and design choices, but inevitably, even the best planned approaches will sometimes turn out wrong. We can work to eliminate lots of our technical debt, but the costs of reducing it fully to zero aren't worth the incremental benefits for moving from small levels of tech debt to no tech debt.

Tech debt measurement is still lacking, but teams have a sense of how it impacts them

To get a precise measurement of technical debt we need to combine together measurements around specific issues and antipatterns as well as meaurements of decreases in productivity/velocity as a result of tech debt in our codebase. Unfortunately, these measuremetns are incredibly difficult to get, and it's to be expected that teams struggle to accurately measure how much tech debt they face. But, the level to which teams don't measure their technical debt is still surprising. Fewer than 20% of all developers surveyed work on teams that do anything to measure their technical debt.

But, teams actually feel that tech debt is slowing them down and they try to take this into account in their estimations. Because we struggle to measure tech debt, these measurements are often based intuition than on data. Almost 80% of teams reported that they take the part of their project they will be working on into account when they estimate project timelines. The delays we encounter when working in different parts of a codebase (eg due to complexity, brittleness, existing bugs, etc) are all forms of tech debt. This suggests that even when teams have a limited measurement of the amount of tech debt they're facing, they still are accounting for it in their day to day planning.

The link between test coverage and technical debt

Having broad test coverage is important for reducing the risk of bugs making it to production, but that's not the only benefit of having tests. 47% of respondants who had medium or high levels of technical debt said that their code had 'No Tests' or 'Only a Few Tests'. On the flip side, only 23.5% of teams with low technical debt said the same.

Having more sufficient tests allows teams to more confidently make large scale changes to their codebase and undertake more significant refactorings, key to reducing tech debt. The process of going through creating these tests also requires teams to show that they fully understand what each piece of their project is doing, reducing some of the complexity and confusion that often contributes to high tech debt. But, there is a bit of a causal question here. Are teams with better tests better able to improve their code and reduce their technical debt? Or are teams who have processes in place to manage and reduce their tech debt more likely to have similar processes in place to ensure their codebase is widely tested? There's no obvious answer, but either way, going through the process of making sure your code is well tested is a good choice and might help manage your technical debt.

Clear naming is important, but it's not the only thing

Confusing, unclear, and inconsistent names are often cited as one the biggest causes of technical debt. But, it's only one of several key types of tech debt that heavily impacts teams in our survey. Inconsistent naming and terminology ranked as the biggest driver of technical debt for teams with medium or high technical debt, but poor architecture, unclear code side effects, and inconsistent code styling had almost just as high of an impact (all within 10%). Dead code on the other hand, had a much more limited impact on teams' technical debt.

Nearly every engineering team out there is running into technical debt in one way or another - even if we struggle to measure it's impact. Keep an eye out for the next part of our series on tech debts impact on engineering teams.

Are you looking to reduce your tech debt or prevent it from building up in the first place? Learn how Sourcery can help your team improve all your Python code and ensure it's following your team's best practices.