What is “tech debt”?
Explained nicely by Asana’s team, “technical debt is the cost of additional work caused by choosing the quickest solution rather than the most effective solution.” Tech debt can also be “the result of a calculated move to both meet software deadlines and ship high quality code within sprints. In other instances, technical debt is the result of an unavoidable mistake made when releasing a software update.”
Fixed v. Variable time for tech debt
With all that said, at some point you have to pay down your principal and interest. Consequences of tech debt that lingers too long can include increased complexity and difficulty in maintaining and updating the codebase, slowing down team velocity and most importantly, frustrating the heck out of the team. It’s not fun to code in a ratty environment.
Before we dive into the hotly debated topic, let’s define some terminology that we’ll use for the discussion.
- Using “fixed” time. Many teams spend a percentage of their time each sprint fixing or improving tech debt. We often hear 20% quoted by teams.
- Using “variable” time. This just means that individual issues that need to be addressed are identified, and then prioritized on the roadmap. An extreme example would be: one sprint has 0% tech debt in it (aka is all feature development) and the next sprint is 100% focused on tech debt.
Most high performing teams we spoke with allocate a fixed percentage of time to addressing tech debt. This doesn’t mean it’s right or wrong. Why do they do this? Engineers intuitively know what and where the issues are, but it’s hard to explain yourself to Product. And in the absence of Product and Engineering speaking the same language, the business will look for impact, or numbers. And there aren’t yet clean ways to quantify tech debt in aggregate across the system.
The benefits of fixed time (ex. 20%) per sprint
You don’t have to explain yourself to Product. It’s frustrating to spend the time and energy detailing and justifying the issues without a quantifiable way to show the impact of the proposed changes.
If you don’t have the loudest or most persuasive voice in the room, you can still get things done.
If you’re constantly fighting to get the biggest impact projects prioritized, the smaller things get left behind, leaving tech debt to pile up.
The benefits of variable time (prioritizing each initiative)
If you’re persuasive and can clearly explain the problems to Product, you’ll likely get more than 20% prioritized.
If there’s a big problem that needs to be addressed, you leave the door open for prioritizing a major change, like a redesign.
So where does this leave us?
There’s no universally accepted framework for quantifying debt, making it difficult to share impact in a way that’s accessible to the business. We’re seeing big companies like Amazon, Spotify, and Stripe investing in measuring developer experience and tech debt, to prioritize the health of the team (in terms of velocity and frustration level), the health of the codebase, and ultimately the business.
