This is part three in our ongoing series on technical debt. Check out part one, The Cost of Technical Debt, and part two, When to Take on Technical Debt.
So far in this series we’ve talked about how useful the term technical debt is, and how to use the framework to make smart business decisions for taking on and paying off that debt. Today, we’re going to talk about another, much less technical, term: a mess.
Technical debt includes any tasks you choose not to do now, but will continue to cause problems until they are completed. Like any buzzword, the term can be misused to soften or disguise what’s actually going on — a mess. The term mess comes from Uncle Bob on Clean Code, who doesn’t pull any punches: “A mess is not a technical debt. A mess is just a mess.”
Here are a few of the ways we determine if something’s a mess.
Check the debt:asset ratio
A toxic asset is a mess. You have a toxic asset when the amount of debt is greater than the asset. To find out your debt ratio, take your total debt divided by your total assets. The higher the ratio, the riskier the asset.
Toxic assets aren’t fun and they typically aren’t a single person’s fault. Sometimes a toxic asset is the result of an acquisition that seemed promising and isn’t. Or, it’s the end result of sunk-cost decision making: We’ve come this far… It’s usually a painful realization. When you have more debt than you have assets, you’ll likely spend all your time and money paying interest and never paying on the capital. That is, you’ll be servicing the debt and not servicing the asset.
One way to think about this question is to ask yourself how much it would cost to build the right thing from scratch compared to how much it will cost to transform the existing project into that right thing. The closer those two numbers are to each other, the riskier your current asset. When they cross paths, and the new build is cheaper than the old, you definitely have a toxic asset.
For example, if your friend has a clunker of a car that’s worth $500, but requires $1,000 of repairs every month to keep driving, would you recommend they keep the car (and the monthly repair costs), or would you suggest they get a different car? And, how much should they spend on that new car? We recognize it doesn’t feel good to realize your asset isn’t actually an asset, and as an outside team, it’s easier for us to have objectivity on the issue.
Make the debt explicit
The ability to take on debt safely, track it, manage it, and pay it down varies among different organizations
Just like debt can become a financial mess — a massive pile of past-due bills, or a wince with the credit card swipe — technical debt can be a mess when it’s not explicit. The more confusion or vagueness you have around your debt, the more likely it’s a mess.
You can make sense out of the mess. Have frank discussions about the debt. Making explicit decisions around it. Take stock of your current debt — and track it going forward. You want to know how much you have, how much you’re accruing, how much the debt is costing you, and how and when you plan to pay it down.
The more you can move away from, We don’t know and We can’t bear to know, the better able you’ll be to manage and repay your debts, and get out of “mess” territory.
Gauge your discomfort
Finally, it’s easy to call something a mess. And it can be an overreaction.
To determine if your mess is really a mess, ask yourself and your team how comfortable they are with technical debt. And, do different teams in your business have different thresholds?
We’ve found that business units are often more comfortable carrying technical debt than the technical units. It makes a ton of sense: the debt is more visible to the technical team; the payoffs of incurring it are more visible to the business unit.
It’s also not hard to imagine a technical team with high standards seeing some sloppy code and calling it all a mess. Challenge your team to articulate the issues with the code and their severity. For example, some sloppy code could result from hiring a junior programmer — but there’s are a million great reasons for hiring a junior programmer. (We’ll train them! They’ll grow! They’re hungry! They’re available! They’re within budget! We are all beginners at some point!) If the team is taking shortcuts, writing code with a lack of comments, or using generic variable names, that’s a “mess” that’s easily remedied with early and often feedback.
Just like any relationship with varying financial perspectives (e.g., being a spender who’s married to a saver or vice versa), a disconnect like this requires conversation and some compromise.
Our POV: If it’s a mess, say so.
We’re grateful for the term and framework of technical debt — it’s helped us understand and convey the tradeoffs in many development decisions. We’re also glad to know that it’s not always so complex. A mess is still a mess. So, stay candid and direct in discussions and don’t hide the truth beneath a buzzword.
