When a system still works, but the organization can no longer afford to change it.
Debt isn’t necessarily bad
Debt is a legitimate financial instrument. It allows us to invest today in exchange for future obligations. We accept that borrowing comes at a cost: repayment of the principal, plus interest.
Technical debt applies the same reasoning to software development. We take shortcuts to deliver sooner, accepting that correcting them later may cost more. Sometimes this is a perfectly rational decision.
The problem is that, unlike financial debt, technical debt rarely comes with a repayment schedule, an allocated budget, or someone explicitly accountable for managing it. The project delivers. The product inherits the debt.
Paying the interest
Over time, maintenance becomes more expensive. Changes take longer. Workarounds accumulate. Knowledge becomes concentrated in a few local heroes who understand how everything fits together. The organization keeps paying interest, often without recognizing it as such.
And because the system continues to work, there may be little urgency to address the underlying debt. Until something happens.
The perfect storm
Imagine an organization operating heavily customized, home-built applications. They support the business, but carry decades of accumulated technical debt. Then a vendor withdraws support for a critical integration platform.
Without the accumulated debt, replacing the integration platform might have been a manageable intervention. But the existing systems have become so difficult to modify that a limited replacement is no longer attractive.
Instead, the organization decides to replace its home-built applications with commercial ERP systems, redesign its business processes, and consolidate its application landscape. A transformation program is born.
The external event triggered the transformation, but the accumulated technical debt helped make it necessary.
Without that debt, the perfect storm might never have happened.
Technical bankruptcy
A system doesn’t have to stop working to become technically bankrupt. It may still perform its existing functions reliably. Users may even be satisfied with it. But adapting it has become prohibitively expensive, risky, or slow.
Technical bankruptcy isn’t when a system stops working. It’s when the organization can no longer afford to keep it evolving.
The transformation program becomes a way of dealing with the accumulated debt. Some debt disappears when the old system is retired. Some must be repaid through migration, integration, data cleansing, and reconstruction of business knowledge. Some may even be carried forward.
Starting over
The transformation receives substantial funding, executive attention, and organizational commitment. Eventually, the new solution goes live.
But what has changed? The new systems will also need maintenance and adaptation. They will face delivery pressure, changing requirements, and competing priorities. And they will accumulate technical debt. Unless the organization changes how it manages its products, the same pattern may repeat itself.
This is where Product Stewardship becomes relevant: someone needs to be accountable for the product’s long-term sustainability, including understanding, managing, and deliberately accepting or repaying technical debt. Not eliminating debt at all costs, but preventing it from becoming unmanageable.
The question we rarely ask
When an organization launches a transformation because its existing systems have become too expensive or difficult to maintain, shouldn’t we ask how they reached that condition? What investments were postponed? What decisions contributed to the accumulated debt? And why was replacing the system easier to justify than maintaining its ability to evolve?
Most importantly:
What are we doing differently to prevent the new systems from following the same path?
Otherwise, we may simply be starting another cycle of technical debt accumulation. With the next transformation already waiting somewhere in the future.
Leave a Reply