Wholesale "refinancing tech debt" is not "digital innovation" – but can you tell the difference?
A Test, a Tell, and a bit of Wisdom for dealing with business stakeholders who want to sweep the ugly bits under the rug
A lot of my work, and a lot of software development in general is about creating abstractions.
Application Programming Interfaces (APIs) are a key method for abstracting (and orchestrating) old IT systems, new IT systems, really any IT systems.
In very simple terms: Building or buying a system or platform to “put on top of” or to “be an umbrella over” another usually older and problematic system or platform.
Of course, “the only constant is change,” which means that any software or IT system becomes outdated quickly. A business could need to abstract the proverbial AS/400 in the basement, or maybe their ongoing investment in a walled-garden platform like Salesforce is boxing them in competitively.
Using abstractions offers us a pattern to build a new layer on top of an old layer without replacing the old layer.
I often say, “abstractions create freedom.”
That freedom can come at a price. Abstract things again and again … and again … and then just pick whatever metaphor you want to use to justify it:
Prioritizing our resources
Deferring the decision on that
Kicking the can down the road
Somebody Else’s Problem (an “SEP”!)
Not my problem
…
DIGITAL INNOVATION!
What do you mean by “refinancing”
Abstractions can bring freedom, but understand the trade-offs you’re making if it feels like you’re just further burying technical debt.
This article from LaunchDarkly titled, Technical Debt: Why We Take It On and How We Pay It Off is a great read on the topic of refinancing technical debt. It begins:
Technical debt is a metaphor to understand how the tradeoffs we make in software development have long-term consequences.
It is traditional to compare software technical debt to financial debt: both kinds of debt are frequently taken on to achieve a long-term goal, both incur a kind of interest that must be added to the original cost of the loan, and both have a lot written about how to avoid or leverage them.
In theory, technical debt, if well-structured and paid off reliably, does not hurt an organization any more than a mortgage hurts a homebuyer.
In practice, organizations writing software sometimes accidentally take out high-interest loans to make progress that doesn’t pay off. Code debt is not bad in itself, because everything about software engineering is a set of tradeoffs. Technical debt and short-term-only code choices are dangerous when they are silent, unacknowledged, and there is no plan to pay them off.
The only thing I disagree with here is the generous use of “accidentally” – it’s no accident if businesses know what choice they’re making, and still make that choice.
Side note: I always get a smile on my face when I see an URL that shows what the working title of a post is, like
technical-debt-the-silent-killer-in-scaling-software
The Test: Innovation, or Refinancing?
Here’s an easy test to determine if a business is truly doing innovation work, or if they are merely and riskily refinancing tech debt:
At the time the abstraction is planned, is there also a plan being made to resolve what is being abstracted?
If “yes” – awesome!
If “no” – consider yourself warned.
The Tell: How to read a business stakeholder to see which way they’re going to go
I’ve been in many meetings where I’m presenting (selling) concepts and plans for how to create abstraction in a business’s tech stack. At some point when the energy & excitement is up, I’ll say something to the effect of:
“Yeah, and with that approach, we can just refinance your tech debt so you don’t have to worry about it now!”
In that moment, I am looking for the business stakeholder I’m talking with to pause and consider what I said.
In every instance, I get one of two responses:
They lean in… “Yeah, that sounds like a great idea!”
They lean back, their face may get a bit quizzical … “Uhhh, wait, that doesn’t sound like a good idea…”
From that response, I have a good idea how the rest of our working relationship is going to go.
A bit of Wisdom: IT/Software Buyer Maturity
The idealist in me likes to think that this comes down to a matter of experience and “buyer” maturity. A business stakeholder who hasn’t been burned by lurking and forgotten technical debt may not have been hurt badly enough yet to have developed a strong aversion to it.
The business stakeholder who has been burned, and burned bad, knows better.
I’ve been around long enough that while I try to cling to my idealism, I know not everyone thinks or acts the same way. (Sometimes that includes myself 😅)
Empathy in software development can also mean, “realizing that someone is making decisions with a short-term view”…
Sometimes it’s because they’re under immense pressure in the business.
Sometimes it’s because the person you’re working with wants to get promoted – or save their job.
In their heads, they’re going to make the tech debt SEP – Someone Else’s Problem.
Is it now going to be your problem?
