Published on 22 January 2020 by @mathiasverraes
“Technical debt” is a metaphor for all software design choices that turn out to be suboptimal, no longer valid, or just plain wrong. These choices incur a cost on future development, and the shortcuts taken today will later slow you down until you “pay back” the debt by fixing the problems. And it’s not only code: Artifacts like architecture, documentation, tests, and domain models can all suffer from technical debt.
Technical debt can severely drag down development. And paying back all debt by replacing all software isn’t usually very feasible either. But, like financial debt, technical debt is not always a bad thing. Debt allows you to invest in something before it makes money. Taking shortcuts when bringing a product to market allows you to test a business model cheaply, and it makes it easier to throw away the code if it turns out to be a bad idea. And often, the debt exists because the business has grown and evolved, and the design choices that were valid early on no longer are.
All this to say that the problem isn’t technical debt; it’s unmanaged technical debt. In any company, the CFO knows exactly how much financial debt there is. There are spreadsheets, quarterly reports, payment plans, and options to refinance or sell debt. But ask your CTO how much technical debt your organization has, and you’ll get an awkward “uh… a lot?” as an answer.
So how do you manage debt in a fast-moving agile project?
The Wall of Technical Debt is a surface in your office where you visualize issues on sticky notes. It’s easy to start and maintain, and yet it has a profound impact on how you choose to add, reduce, pay back, or ignore debt. It’s by no means intended as a complete solution to scale the management of debt, but it works precisely because it requires no buy-in.
Creating your own Wall of Technical Debt is simple: Make the debt visible, build a habit, negotiate regularly, and give away control.
Image by Pim Elshoff. Licensed under a Creative Commons Attribution 4.0 International License.
Pick a wall in the space where your team works. Make sure it’s publicly visible. Label it the “Wall of Technical Debt.” Draw a nice dramatic logo. Make sure there are sticky notes and markers around so people can easily add to it.
Whenever you work on code and encounter technical debt:
Don’t forget to also add sticky notes whenever you introduce new technical debt yourself. And be honest. There’s no shame in this, because you are not your code. Remember technical debt is an investment, not a crime — unless you’re hiding debt, in which case you’re cooking the books!
When this becomes a habit, the wall becomes an information radar of the state of your system.
As the Wall of Technical Debt grows, people in your organization might get a little nervous. That’s OK! The debt was always there; you only made it visible. Hopefully some of the habits start changing.
Whenever someone gets up to add another dot to an existing sticky note, discuss it with the team. Compare the cost of the measured wasted time to the estimated time to fix the debt. Sure, it might take a day to fix the code, but if you keep losing two hours over it every week, the time spent fixing it will pay for itself soon enough.
Or, perhaps fixing it isn’t worth it. That’s no longer a matter of aesthetics or opinion. Rather, it’s a matter of empirically collected metrics. Congratulations, you’re negotiating tradeoffs as a team.
Meanwhile, when someone adds a sticky for newly discovered existing debt, consider if it’s something the team could fix right away. Of course, it’s perfectly fine to put it on the wall; that’s what it’s there for. However, when you’re introducing new debt, it’s different. Consider if the team could choose not to take the shortcut and instead fix the code while it’s still cheap. The question shouldn’t be “Do we have time now?” It should be “Is it worth paying interest on this later? How much?” The answer could range anywhere from “It doesn’t matter, just commit it,” to “Lots of things will depend on this, so let’s get it right before moving on.”
The point is not to fix all technical debt. The point is to learn to negotiate when to add it, when to fix it, and when to avoid it. Before, this happened mostly invisibly: Individual team members added or fixed debt without knowing all the facts. Now, the collective brain power of the team can be applied, using real data.
Now we get to the real magic. Because the Wall of Technical Debt is so visible, managers should start to take notice. (If they still don’t, use a fat red marker to add some € or $ signs to the Wall. Money is the universal language, and lost money stings twice as hard.)
Normally, when a team asks for time to spend on technical debt, there’s no direct tangible benefit to the users or the business. A manager can’t decide whether those fixes are of critical importance, an attempt to play with shiny new tech, or a desire to have prettier code. Even for a manager with a deep technical background, if they’re not directly involved with the code, it’s impossible for them to judge the importance of a fix.
But with the Wall of Technical Debt, it’s different. Now it’s not about opinions. It’s not about the desire to be a craftsperson who writes elegant code. It’s not about solving challenging puzzles. This time, it’s about facts, numbers, debt and interest payments, and returns on investment. You’re speaking the manager’s language. Good code as an asset, bad code as a liability. They’re trained to look at the numbers and make decisions. They’ve got the methods for it: CBA, OODA, PCDA, SWOT, …
So now, give away control. The manager knows more about the company strategy, the budgets, the risks. Let them decide, with your help, what to fix and when to plan it. The numbers enable that.
I started writing and speaking about the Wall of Technical Debt in 2013, after my team and I had developed a first version. One of the first companies that adapted our approach, was a small startup I was consulting for. The little wall space they had was already used by business plans and app mockups. So the team put the sticky notes on the office’s only window. The joke became that whenever the room got too dark, they knew it was time to refactor!
More importantly, they had been stuck alternating between perfectionism and hacking things to get to market faster. The Wall of Technical Debt helped them break out of that cycle, and they launched soon after. I’ve since heard stories of teams in all sorts of companies using it successfully. Perhaps you could be next.
I wrote this article for Visual Collaboration Tools, a book that Kenny Baas-Schwegler and João Rosa are editing. It’s loosely based on “Managed Technical Debt”, Verraes 2013. Thanks to Indu Alagarsamy, Rebecca Wirfs-Brock, and Natalye Childress, for reviewing the drafts.
Follow @mathiasverraes on Twitter.
This work by Mathias Verraes is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 License.