The lifeblood of a piece of software is the delivery of new features. Not only is that how you can differentiate your software from the competition (the faster the better!). But also, it’s very hard to market your software without new things to use as fuel. It’s so much easier for a marketing team to work with a constant flow of new features. How do you balance the delivery of new things with maintaining what you currently have, though? It’s an important question, as it seems a common default to simply focus on new features. After all, you can directly measure the results of new features. What does addressing technical debt accomplish?
What is technical debt?
As software is developed, it’s difficult to know the whole shape of what an application needs to be. Even if developers have a good guess, it will undoubtedly change over time. Software is always evolving. Responding to user demands as your software gets used is critical to success. However, change often means your software goes outside of the originally envisioned bounds. Combining this with just small mistakes in design and architecture, you end up needing software to change in a way it wasn’t originally designed to accommodate. We call this a form of technical debt. There are many other ways to accumulate this debt, but I’ll focus on this one for its prevalence.
Low feature pressure on a team will result in lower technical debt, as developers will have more time to consider architecture and flexibility, and spend time coding it. High feature pressure will often result in faster feature delivery, but also higher technical debt. Developers will have less time for these things and are more likely to write the simplest way to accomplish a task, even if it is less flexible, more brittle, or less performant. At its core, technical debt consists of things that need to change because they cause some kind of pain point or risk. This could be anything from costing developers more time (repeated menial tasks), to high-risk code that has a high likelihood of bugs or performance issues.
There’s a cost to ignoring it.
It can be tempting to focus on features as they have directly visible results. That is secretly creating a minefield, however. Although it’s invisible, technical debt can be expensive. The longer you leave it, the more it’s costing you behind the scenes, AND the more expensive it is to fix. It can secretly slow all your developers down or make them do more complicated implementations. It can also result in higher bugs in production or leaving potentially dangerous exploits in your software. There is an unlimited set of problems this could be causing, and the only way to truly know is to ask the developers themselves.
I’ve seen entire companies fail over the cost of unaddressed technical debt over time. It eventually becomes so burdensome to create new features and so expensive to maintain existing features that a company starts to struggle under the weight of it. I’ve worked at companies where the QA team was larger than the developer team, simply because it was so hard to verify new releases were going out bug-free. This is incredibly expensive and only addresses the symptoms, not the actual cause.
What do we do?
The 20% rule outlines a system where your engineering team gets 20% of their time to do as they see fit. A lot of the time, this will mean refactoring technical debt. After all, developers feel that pain, and they worry about those risks. However, this isn’t exactly a guarantee, and it’s certainly far from targeted.
Sometimes, the biggest or most dangerous technical debt isn’t something directly causing developers pain. Maybe it’s migration to a new database system to allow for better performance, or future feature capability. Instead, I propose a different, more straightforward plan: put technical debt in your backlog of work like everything else.
The default that this accomplishes is that it puts technical debt tasks in the same category as regular work. They’re all in the same bucket! This doesn’t mean they’re equally important, of course, but it does mean they get talked about at the same time. This could be your refinement, or your product team’s prioritization, or whatever system you use. It means it has to be considered alongside new features.
If the people doing prioritization don’t understand how important some of the debt is, be sure to include someone technical to help! Everyone has the same end goal: successful software. So let everyone collaborate to find a good balance!
It’s all about compromise.
Remember that every rule of thumb is only as good as the average situation! Technical debt is incredibly important, but how important can change depending on your organization’s situation. You could need more time or less time. Maybe you don’t have time now due to investor pressure and need to delay. Every situation has an answer. The important thing is to keep technical debt in mind and ensure that product and engineering are having conversations about it so everyone is aware. Now go out there and squash some debt!