Technical debt is just a fact of life. Over time, it can feel inevitable that our codebase degrades. But it doesn’t have to be that way.

Yes, you will have technical debt, but you don’t need to let it grow out of control. Once you’ve paid down the worst offenders, how do you change your engineering organisation in a way that keeps technical debt at bay. Not entirely gone, but also not evergrowing?

Bake in paying off debt into projects

One of the most effective ways of regularly paying down technical debt is to ensure that your technical scoping looks deep enough at the current implementation of what you’re working with to understand if there’s technical debt you can pay off as part of the project.

For example, if you’re building something heavily asynchronous, are there improvements you can make to your queue or pub/sub patterns to make everything better for the future? Or if you’re providing an asynchronous download (such as building a CSV export, which generates a download link that the user can then access), and you’re already doing that in three different places, can you turn that into a pattern?

Baking this work into projects is by by far the most effective way to keep technical debt under control, as it ensures your entire team is regularly thinking about it.

Run pattern parties

A concept I was introduced to at incident.io is a pattern party. You can read all the details of what they are and how we run them in my coworker Kelsey’s excellent blog post.

In short, a pattern party is a focused effort by the entire engineering team to refactor the codebase to follow one new pattern. It starts by moving all existing code that will be modified by the pattern party to a legacy folder, and then migrating it to its new place piece by piece.

By moving it over to legacy, you also ensure that even after the pattern party is over, you ensure engineers are aware of when some code isn’t following your patterns.

Turn big problems into projects

Some technical debt just doesn’t neatly fit into a product project, but is large and painful enough that you still want to solve it. In those cases, it’s useful to keep a list of these large pieces of technical debt, and then committing to work through a given number of them every quarter. How many of these you run as dedicated projects each quarter will depend on how much technical debt you have, how much time you’re willing to spend on paying down technical debt, and how large your team is.

Conclusion

Keeping technical debt at bay requires a proactive and disciplined approach. By integrating debt repayment into regular projects, organising pattern parties, and addressing large debt pieces as dedicated projects, you can maintain a healthier codebase. These strategies help ensure that technical debt remains manageable, allowing your team to focus on delivering high-quality software.