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. They incur a cost on future development. The shortcuts taken today will later slow you down, until you “pay back” the debt by fixing the problems. And it’s not just 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 us to invest in something before it makes money. Taking shortcuts when bringing a product to market, allows us to test a business model cheaply, and 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, are not anymore.
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 organisation has, and you’ll get an awkward “uh… a lot?” as an answer.
The Wall of Technical Debt is a surface in your office where you visualize these issues on sticky notes. It’s easy to start and to maintain, and yet has a profound impact on how we 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. It works precisely because it requires no buy-in.
Simple: Make 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 is working. Make sure it’s very publicly visible. Label it as the “Wall of Technical Debt”. Draw a nice dramatic logo. Make sure there are sticky notes and markers around.
Whenever you work on the code:
Remember to also add sticky notes whenever you introduce new technical debt yourself. Be honest. There’s no shame in this, because you are not your code. Remember that technical debt is an investment, not a crime — unless you’re hiding debt, then you’re cooking the books!
As the Wall of Technical Debt grows, people in your organisation 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, that’ll pay itself back soon. Or perhaps fixing it isn’t worth it? That’s not a matter of aesthetics or opinion anymore. It’s a matter of empirically collected metrics. Congratulations, you’re negotiating tradeoffs as a team.
When someone adds a sticky for newly discovered existing debt, consider if it’s something the team could fix now. But it’s perfectly fine to just put it on the wall, that’s what it’s for. Is there no evidence that this problem will keep costing you? Just let it collect more dots for now.
However, when we’re introducing new debt, it’s different. Consider if the team could choose not to take the shortcut, and just 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, 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 is 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, add some € or $ signs with a fat red marker on the Wall. Money is the universal language, and lost money stings twice as hard.)
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 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 a 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, returns on investment. You’re speaking the manager’s language. Good code as an asset, bad code as a liability. They’re trained for this: look at the numbers, make decisions. They’ve got the methods for it: CBA, OODA, PCDA, SWOT, …
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.
After reading my 2013 blog post, a startup introduced the Wall of Technical Debt. They were a very small company, and all the wall space was already used by business plans and app mockups. They put the sticky notes on the office’s one 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, and they launched soon after. We’ve since heard stories of teams in all sorts of companies using it successfully, and perhaps so can you.
This article is written for “Visual Collaboration Tools”, a book that’s being edited by Kenny Baas-Schwegler and João Rosa. It’s loosely based on “Managed Technical Debt”, Verraes 2013. Thanks to Indu Alagarsamy and Rebecca Wirfs-Brock for reviewing the draft.
Follow @mathiasverraes on Twitter.
This work by Mathias Verraes is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 License.