In my previous posts about tech debt, I focused on how we can help organizations remember their debts, and on understanding how tech debts are funded and paid back.
These topics hit a raw nerve with coders and testers. Those in the trenches often feel very keenly the cost of doing things in a messy way, and it’s common for them to worry that others don’t “get it.”
They’re not wrong to worry.
However, today I’d like to put on my executive hat and discuss tech debt from a perspective that code jockeys sometimes miss, because blindness is not just an executive disease.
Debt as Leverage
When you hear the word “leverage” in business circles, people are talking about debt: a “highly-leveraged” firm is one financing large portions of its strategy through debt; “leveraged buyouts” are transactions where the buyers borrow vast sums of money from a risk-taking lender to take a company private.
Technogeeks (like me): business people are not dumb. Why did they settle on this metaphor of debt as leverage?
The answer is that debt can allow a company to concentrate enough capital in a short enough timeframe to make high-impact strategic moves that would otherwise be impossible. It’s an enabler and multiplier.
Debt is a fundamental machine in the business toolkit, just as levers are a fundamental machine for mechanical engineers. Almost all businesses use debt to some extent. If a CEO can borrow capital at 9% and produce 12% ROI with it, and if the risk implied by that gap is low enough, then not borrowing would be a violation of his fiduciary responsibility to stockholders. In fact, I’d go so far as to say that capitalism is somewhat founded on the notion that debt allows money to flow to its most efficient use.
Don’t get me wrong. I detest personal debt. I think recent financial excesses, and the ensuing mess as we were forced to confront arbitrage and Wall Street shenanigans, are deplorable. I think most first-world countries are neck-deep in debt and are thus setting themselves up for hard times for many years to come.
I’m just saying that debt, like any other tool, has legitimate (and intelligent) uses, and it’s not going away.
Now, think about “tech debt” from this perspective for a minute.
Yes, the tech debt is ugly. We hate the way it complicates our designs, slows our velocity, compromises our future.
But what have we been able to buy with our loan?
If the answer is “nothing worthwhile,” then shame on executives. But if the answer is “we kept the company alive and entered a key market or landed a lighthouse customer,” then maybe it was the right move.
Of course, just because it was smart to buy on credit doesn’t mean you should make minimum payments forever. And just because the lender isn’t pounding on your door doesn’t mean your payment isn’t due.
I can remember my grandmother whistling in the kitchen as she sealed an envelope and put a stamp on it.
“What are you mailing?” I asked.
“My mortgage payment,” she said with a smile. “The last one.” (I think it was the last; maybe she was still a few months away but could see the finish line. Anyway…)
That moment came after years of patient, disciplined effort on Grandma’s part. It did not come in a single, giant payback.
Technogeeks: here is another blindness that we sometimes suffer from. We think that if we push hard enough and make enough noise, we’ll convince someone to pay back a tech debt in one grand gesture.
Grandma didn’t have that kind of money, and neither do most of the companies we work for.
Thus, two words must get imprinted on our hearts and minds: discipline and patience.
Circle of Concern, Circle of Control
This is something you can control. Yes, you. You may not have a manager or executives that totally agree with you about how painful your tech debts are. You may not have veto power on the dev budget. You may not sit in strategic board meetings.
But you can get in the habit of mailing a check every month. Even the worst spiky-haired boss probably can’t stop you.
Read Refactoring (Martin Fowler). Ponder.
Next time you’re fixing a bug, take an extra 5 minutes to document the function better. Then make that practice a habit.
In the spirit of my post about teaching to accelerate your own learning, talk about what you’re doing, and why. I remembered Grandma’s comment for 35 years; you’ll make an impression on others.
Next time a behavior of the code puzzles you, write a unit test to understand it.
Next time you hear yourself complaining about how hard it is to install the product, assign yourself to spend half a lunch break improving a smart default.
One Last Insight
You may be saying: “That’s all well and good, but it’s a drop in the bucket compared to the massive problem we have with X.”
Even if that’s true, I guarantee that at least half of the massive problem you have with X is one of attitude. You’ll never solve it if you can’t generate some momentum and optimism for the future. Give yourself a reason to believe things can get better, and watch how much more tractable your tech debt becomes.
Identify a low-cost, high-impact habit that will raise your spirits and your team’s vision with regard to tech debt, and ingrain that habit in your own day-to-day work.