Technical Debt and Modernization

One of the primary reasons for a complete rewrite of a system is to retire accumulated technical debt in a legacy application. Technical debt is at the heart of the common observation that legacy applications consume ridiculous amounts of money to keep the lights on, yet still it takes forever to make even minor changes. Decades old applications become brittle and break easily, so programmers not only have to make the change requested, but have to fix everything that they inadvertently break while doing so. This is the “spaghetti code” problem raised to the nth power. A rewrite or other replacement will indeed fix the problem, at least for now, BUT - then it will start over again in a new cycle.

Technical Debt = Deferred Maintenance

The analogy that I use for technical debt is infrastructure maintenance. Once you build a new bridge, proper civil engineering will give you a maintenance budget. If you spend less than that budget, for whatever reason, a form of technical debt accumulates. If you get a budget increase, it is likely to cost you more to put the deferred maintenance right than the sum of the foregone maintenance expense, possibly a great deal more. Worse, you run the risk of a catastrophic failure, a tiny risk at first, but one that grows and grows over time..

I remember when in the late 1970s an engineer for New York City found that one of the fundamental supports of the Williamsburg Bridge over the East River was 90% corroded away due to deferred maintenance. Had it failed, the bridge would have collapsed. Putting it right was very, very expensive, but the direct and indirect costs of a collapse were almost impossible to calculate.

The photo is from a section of the West Side Highway that did collapse in the early 1970s. Like the Mianus River Bridge failure in Connecticut in 1983, its failure was due to deferred maintenance.

Technical Debt = Costly and Brittle Software

Technical debt in software engineering is directly analogous to deferred maintenance in civil engineering. If you keep adding features to your bridge without fixing the structural problems you’ve been ignoring, doing so becomes progressively more expensive and creates danger of collapse.

Additional work on an aging software application, adding features required by the business, steadily increases in time and expense until either a catastrophe happens (fortunately rare) or the decision is made to invest in rewriting the system or replacing it in some other way.

Once the replacement application is in place, however, then the cycle repeats. This is equally true of a package application as for an in-house custom built application. Does anyone ask about the extent of accumulated technical debt in an off the shelf package application under consideration? Not that I’ve ever heard.

This cycle does make a certain amount of sense, however, because business executives have difficulty knowing whether the requested maintenance budget is making a sensible allocation of resources or allowing their technicians to gold plate their workstations. Thus, the reflexive strategy is to minimize the budgets for maintenance.

Minimizing maintenance budgets does at least make some sense, or it does to business executives. Who knows if the software would be any better if the technicians had a free rein on budgets? The executives certainly don't.

The obvious response is to educate the executives, and set up a comprehensive code quality review and enforcement system. I'm all for this, and cheer sites that implement and maintain such a system.

Declarative Languages Solve the Problem

However, there is another approach. If you look deeply into the matter, you will find that the problem is closely related to the fact that the software was implemented in a procedural (or "imperative") language, such as C, COBOL or Java, as opposed to a declarative language. In an imperative language, the order of statements matters. In a declarative language, the order does not matter. This seemingly minor technical point includes a solution for eliminating technical debt once and for all.

Usually the only declarative language that programmers commonly know is SQL. You tell the database what you want, and it has to figure out how to do it. Pre-relational databases required that programmers figure out how to access the data, which is one reason why they have mostly fallen by the wayside.

But there are other declarative languages. For example, in rules engines, you can typically find a decision table option. The columns consist of the rules to be applied, the rows consist of the conditions to be evaluated, and the cells determine the action to be taken. There are many forms of decision tables, but this is the basic idea.

My assertion is that an application built around decision tables will not accumulate technical debt. Think about that. Sure, we could code any decision table logic in Java, but the logic can degrade over time with many different fingers on keyboards. The classic situation is the aging COBOL program where the logic has turned into spaghetti, but this occurs in all imperative languages, some better, some worse. But when the logic is built in a table, there is one and only one action to be taken for each set of conditions. Ambiguity is eliminated.

So, rules engines can be one solution to inhibit the growth of technical debt (though the exact rules engine matters in this regard), but there are others. You can define a domain specific language (DSL) which provides declarative specifications, and the DSL compiler has to generate the executable code at compile time. It is less obvious, but you can't accumulate technical debt in a DSL (though you can in the compiler itself, but that's another conversation). Another example is to use a rules language such as SWRL from W3C.

Oh, and by the way, DSLs and rules languages are a much less expensive and faster way to build a system than with a conventional imperative language. So, you save on the front end and you save on the back end.

Summary

I assert that there are both management and technical solutions to the problem of technical debt, but one way or the other, we need a solution. I see too many legacy sites where the whole budget goes just to keep the lights on, and it's a staggering sum to fix it properly (and frequently risky as well). There are ways to control risk and cost, but they are rarely applied as robustly as they should be. Plus, it's working today, if we try to fix anything we'll probably break it, and I'm retiring in two years so forget it.

At the end of the day, I think technical debt is solvable, but only by people who truly understand both the sociological and technical dimension of the problem, and the financial dimension of a viable solution.

---------------------------------------

Agustín Sánchez Fonseca posted a link to the following article on technical debt in the Application Modernization and APM group: https://www.kiuwan.com/blog/cios-vs-technical-debt-a-burden-for-innovation/. His contribution was the stimulus for the above posting.