What’s the biggest problem with technical debt?
In my opinion, the biggest problem is that it works. Just like the electrical outlet pictured above, systems with technical debt get the job done, even when there’s a hidden surprise or two waiting to make life interesting for us at some later date. If it flat-out failed, getting it fixed would be far easier. Making the argument to spend time (money) changing something that “works” can be difficult.
Failing to make the argument, however, is not the answer:
Brenda Michelson‘s observation is half the battle. The argument for paying down technical debt needs to be made in business-relevant terms (cost, risk, customer impact, etc.). We need more focus on the “debt” part and remember “technical” is just a qualifier:
The other half of the battle is communicating, in the same business-relevant manner, the costs and/or risks involved when taking on technical debt is considered:
Tracking what technical debt exists and managing the payoff (or write off, removing failed experiments is a reduction technique) is important. Likewise, managing the assumption of technical debt is critical to avoid being swamped by it.
Of course, one could take the approach that the only acceptable level of technical debt is zero. This is equivalent to saying “if we can’t have a perfect product, we won’t have a product”. That might be a difficult position to sell to those writing the checks.
Even if you could get an agreement for that position, reality will conspire to frustrate you. Entropy emerges. Even if the code is perfected and then left unchanged, the system can rot as its platform ages and the needs of the business change. When a system is actively maintained over time without an eye to maintaining a coherent, intentional architecture, then the situation becomes worse. In his post “Enterprise Modernization – The Next Big Thing!”, David Sprott noted:
The problem with modernization is that it is widely perceived as slow, very expensive and high risk because the core business legacy systems are hugely complex as a result of decades of tactical change projects that inevitably compromise any original architecture. But modernization activity must not be limited to the old, core systems; I observe all enterprises old and new, traditional and internet based delivering what I call “instant legacy” [Note 1] generally as outcomes of Agile projects that prioritize speed of delivery over compliance with a well-defined reference architecture that enables ongoing agility and continuous modernization.
Kellan Elliot-McCrea, in “Towards an understanding of technical debt”, captured the problem:
All code is technical debt. All code is, to varying degrees, an incorrect bet on what the future will look like.
This means that assessing and managing technical debt should be an ongoing activity with a responsible owner rather than a one-off event that “somebody” will take care of. The alternative is a bit like using a credit card at every opportunity and ignoring the statements until the repo-man is at the door.
Form Follows Function 
I think the problem is with the analogy of ‘debt’. Is the electrical outlet pictured above usually described in terms of debt? No. Put simply, I believe we need another term other than debt to describe the issues we have in the ‘digital’ space.
LikeLike
The electrical outlet is risk in the sense of a bad outcome waiting to happen. It is debt in the sense of needing to be fixed sooner or later.
LikeLiked by 1 person
I’ve tried to make managing technical debt understandable here http://www.gregerwikstrand.com/technical-debt-reduction/
LikeLiked by 1 person
Very interesting. To some extend I think technical debt can also be seen as an opportunity investment : invest in refactoring and you’ll be faster to deliver features later on. The only problem is that, as you said, it is neither visible nor accountable by business people. I heard Michael Feathers say that we need a cost model for software. To be able to value the different things we have in our backlog.
LikeLike
Indeed!
LikeLike