To reduce technical debt assumes that you have technical debt to begin with. Do you? How do you know?
Before we talk about how to approach technical debt, let's make sure we're aligned on what technical debt is, and what it is not.
Simply having issues with redundancy, obsolescence, suboptimal design, performance degradation, neglected maintenance, or unmanaged complexity do not necessarily mean you are experiencing technical debt.
Let's start with a basic definition. I like, "Shortcuts taken to deliver something today at the expense of greater pain in the future." Is that how you view technical debt?
The unsexy but necessary technical work that has built up over time because of some hair on fire request that had to go out the door, all else be damned?
We've all been there. We've all felt the pressure of "the business" demanding ETAs and MVPs and ASAPs and all the acronyms that mean "go faster" while trying to stay on top of all of the cans that have been kicked further down the road as new priorities pile on.
While I feel the term "technical debt" itself is overused and often misapplied to describing backlog management or ineffective technology delivery, it is a real problem that can prevent organizations from moving towards strategic business goals.
When previous decisions to skip important design and refactoring work results in dependencies and rigid structures that force undue complexity and constraints on the organization, you will find yourself facing continuous headwinds.
OK, great! Let's roll up our sleeves and pay off this technical debt, and then we'll be agile and can roll out technology updates faster, faster, faster, right? Not quite.
Assuming you chew through all of the debt, sure it will feel amazing to be unconstrained and have a grasp on the complexity of the architecture. But the thing about technical debt is that you don't want it to come back again.
And if you spend all of this time, effort, money, and political capital to play catch-up, but you don't have the processes and systems in place to keep things running smoothly over the long term, you will find yourself right back in this spot before you know it.
This is why my approach to reducing technical debt balances tactical wins with strategic architectural planning and design.
Identifying and addressing root cause issues coupled with a framework for agile and disciplined enterprise technology delivery is key for addressing the short-term issues while pivoting towards solid long-term processes and practices.
How much of your future is mortgaged with technical debt?
Is it time to get ahead - and stay ahead - of it?