As a codebase gets larger, tech debt is the growing monster that impacts a team’s ability to perform.
It’s very common that a team’s output is slowed down in one way or another, perhaps in its tooling, older components, long-running pipelines, or something else.
And because a team is slower, there’s increased pressure to fix that. Sometimes that means hiring more, sometimes that means pushing more code. The pressure is on to keep delivering. And because the pressure is on, teams often take on more technical debt with hacks and quick solutions to get their work shipped. And because the work needs to be shipped, there isn’t time to patch up the hacks that got them to where they are. The tech debt snowballs, and then the team slows down more. And repeat, forever.
This is rarely a problem associated with a particular stack. If you wanted to make a website today with Knockout or jQuery, it might not be the most modern choice, but it could probably get the job done. You don’t get to this place in a codebase because you need to just rewrite everything in a modern framework. You get here because you probably need a better plan to break the cycle of tech debt.
Make a plan!
There are a few different options for a tech debt plan that could be applied to your teams’ workflows. Have a think about which of these might work for you, whether you do all of them or mix and match:
- Regularly audit debt across multiple categories, like accessibility, code duplication, code coverage, rule violations, performance, security, lack of documentation, complexity, or portability.
- Establish debt limits across categories that are bought in by both engineering teams and leadership teams. If everyone agrees on a level, that makes non-new-feature-work just as prioritized as tech debt work!
- Consider having a dedicated team, group. or rotation for squashing tech debt. I saw a tweet recently from Brandon Dail that hit home on this subject:
I’m starting to think that every product org should have at least one senior+ engineer who isn’t beholden to a roadmap and who just goes around making little quality of life improvements everywhere
— Brandon Dail (@aweary) April 22, 2022
Whether tech debt is a part of a roadmap or not, it’s important to constantly address it. It breaks the vicious cycle of growing debt, and improves an individual developer’s experience tenfold over time!
Getting buy-in
I touched on this lightly before, but a key aspect of fighting against tech debt is making it a priority; it should be just as important as feature work, if not more.
If the team is behind on feature work, or there is a big deadline coming up, that ‘pressure’ part of the cycle will be at the top of everyone’s minds. Timing, when speaking with stakeholders, is key, because it’s often a difficult sell to say, ‘instead of shipping what we promised, we want to fix what already exists.’
Addressing the below questions (or similar) with as much visibility as possible will help put tech debt front and center:
- What do we gain when we opt for a ‘less than ideal’ fix? What will this shortcut save us? If the pros outweigh the cons, the fix may be okay, but the cons are made known.
- Do we fully understand what dependencies are involved and why? If there is something outdated or expensive being implemented, how will it affect the team in the long run?
- How does our velocity change if we do or don’t fix things? The team might be able to work quickly now, but will they for the next feature, and the feature after that?
- How long can we put this off? Some debt is expected, good even, if it means getting an MVP out the door, but how long is that reasonable?
- What is the sentiment around our code? If the developers are unhappy for too long, how long will they stay on the team? How expensive would it be (in time and money) to have to recruit new team members?
This is everyone’s problem – and solution
Everyone on a team, from the developers to the PMs and from the engineering managers to leadership, should be an advocate for maintenance and breaking that cycle of tech debt. It’s healthy for end-users, for teams, and for products!
You will never have a completely debt-free codebase. But, if the debt is manageable, monitored, and maintained, it can work in your favor in a healthy way.
