Pete Hodgson

Software Delivery Consultant

Tech Debt Walls

December 1, 2020

Every codebase carries some amount of technical debt. Every team would like to get better at managing that tech debt.

The first step in managing something is making it visible. A tech debt wall is a simple, effective way to make tech debt visible.

Building a tech debt wall

A tech debt wall is a 2-dimensional map used to track a codebase’s tech debt as individual issues. The Y-axis of this map represents value - how valuable would it be to fix the issue. - The X-axis represents cost - roughly how expensive would it be to fix the issue. Whenever an engineer notices a piece of tech debt, they write a brief description on a sticky (or the virtual equivalent) and place it in the appropriate place on the wall, based on their approximation of the value of fixing the issue and how much it would cost.

an example tech debt wall

When working on co-located teams I’ve built these on a physical wall, using washi tape1 and some sticky notes and sharpies. Nowadays, they’re just as easy to create in a virtual workspace such as a Miro board.

Tech debt regions

While it’s useful just as a shared place to track tech debt, the real value of a tech debt wall comes from having the various bits of debt placed relatively across the two dimensions of cost and value. With a bit of practice, anyone can walk up to a codebase’s tech debt and understand it in terms of four key regions:

regions of tech debt

Issues in the lower-left area of the wall are “quick wins” - the sort of ticket you might pick up if you’re looking to clean the campground a bit on a quiet Friday afternoon.

Issues in the upper-left area of the wall are “no-brainers” - low-cost, high-value work that should be tackled soon. Tech debt walls in the wild don’t often have stickies in this region - they don’t stay on the wall long before being resolved, if they even make it to the wall at all.

Conversely, issues in the lower-right area of the board are “nope” items. The juice is simply not worth the squeeze when it comes to these problems. They’ll likely only be tackled if something changes to make them less work to fix, or more valuable to fix.

The remainder of the wall contains “worthy investments” - tech debt items that are likely to provide a good return on investment but are also meaty enough to require negotiation with other stakeholders to get prioritized.

Using a tech debt wall

I’ve seen teams use their tech debt walls in a few different ways. We already saw that they are an excellent place for an engineer to grab a small “quick win” ticket on a slow day, or while they’re waiting to get unblocked on another work item.

A tech debt wall is also a nice place for a product manager and tech lead to have a regular huddle, talking through new issues, and identifying larger pieces of technical work that can slot into the backlog of upcoming work.

Do’s and don’ts of tracking tech debt

Over time I’ve observed some good and bad practices when it comes to tracking tech debt.

When does a tech debt wall make sense

You might be wondering if a tech debt wall makes sense for your team. My short answer is that if you’re thinking about it, then you should try it. I’ve seen most teams benefit from this practice, and regardless it’s a very cheap continuous improvement experiment for a team to make.

if you're starting to track debt debt, make sure you're also empowering the team to pay down some of that debt!

The times I’ve seen tech debt walls not gain traction is when a team doesn’t have processes in place to actually tackle some of the tech debt they’re now cataloging. That can be demoralizing, and as mentioned early it can also discourage engineers from wasting time adding new items. So, if you’re starting to track debt debt make sure you’re also empowering the team to pay down some of that debt!

Acknowledgements

This tech debt wall concept is something that I picked up from the ThoughtWorks hivemind during my time there. It’s one of the many smart practices which are common across many ThoughtWorks teams, but seem to be quite rare in the broader technical community. This post is my small attempt to right that. If you really want to learn the tricks of the trade, I highly recommend a tour of duty.

I’m not the first ThoughtQuitter to tread this ground. While researching this post I came across this article from Fabio Pereira.

While it sounds very similar, Martin Fowler’s Tech Debt Quadrant is a different idea. A useful model too, just a different one.

Thanks to Will Larson for feedback on a draft version of this post.