Countdown to 2014

In his most recent (October 25, 2010) Computerworld magazine opinion piece, Frank Hayes discusses a debt that corporate IT departments need not pay. Perhaps a majority of readers of the magazine are already familiar with "IT debt", because Hayes mentions the term multiple times within his article but never defines it. The concept is all too familiar to those of us working in the technology space, but I personally do not remember hearing the term until just a few years ago, and since that time the frequency of individuals conjuring up the term seems to have increased.

About a year-and-a-half ago, I came across a discussion of "IT debt" or "technical debt" in a book edited by Richard Monson-Haefel entitled "97 Things Every Software Architect Should Know". While I had mixed feelings about the book at the time of reading (my original review is available here), after listing some of my favorite essays I wrote the following about the contribution by Burkhardt Hufnagel:

By far "Pay Down Your Technical Debt" is the most creative of the lot and could be greatly expanded upon in a title such as that in risk management. Here is an exerpt: "So why the concern over making changes properly now versus later? It's because there's a hidden cost to making these quick and dirty fixes. For financial debts the hidden cost is called 'interest', and most anyone with a credit card knows how expensive just paying the interest on a debt can be. For technical debt, interest takes the form of instability in the system, and increased maintenance costs due to the hacked-in changes and lack of proper design, documentation, and/or tests. And, like financial interest, regular payments must be made until the original debt is repaid".

Earlier in his essay, Hufnagel mentions that such technical debt is incurred due to making a "quick and dirty" fix rather than implementing a fix the "right way" after software is already in production, and that "as the project's architect, you'll have to decide which makes more sense and then convince the decision makers to take your advice; and, as with most architectural issues, there is a tradeoff involved". The complete text of this essay is freely available with the rest of the book here, but I have already quoted half the essay, since most of the essays are limited to two pages.

Apparently, this terminology has been around for quite some time. Ward Cunningham, who reportedly developed the first wiki, is quoted as writing the following in an OOPSLA report dating back to 1992:

Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite… The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.

Last year (2009), Cunningham reflected on his debt metaphor in a short video where he mentions that a lot of professionals misquote him by explaining technical debt as coming back to clean up code after writing the code poorly the first time around. Instead, Cunningham had indicated that technical debt is what is incurred after developing a solution and not properly or fully understanding the problem, and so the code would need to be revisited after greater understanding is achieved.

One can argue over whether Cunningham's original explanation can be expanded upon, but I do think that Hufnagel's limiting the concept of technical debt to released software is too limited. For example, it can easily be argued that debt can be incurred during the first iteration of a four iteration software development cycle even though the associated software has not yet been released to production.

Regardless, however, it appears that Gartner estimates outdated software like Internet Explorer 6 (IE6) has created a "global IT debt" of $500 billion that is expected to rise to $1 trillion by 2015. The closest Hayes gets to a definition of this debt is the "cost to update old apps so they're shiny and new and fully supported". As an architect, I hope that this thinking is severely limited to a small group of CIOs chasing shiny objects.

The point of Hayes' latest opinion piece, however, is to actually argue that it is worth defaulting on some of this technical debt. He goes on to explain:

Look, how did those IE6-dependent users get into that position? They bought into the last big paradigm of software development: the Web browser as platform. Remember? All our apps would be built with a Web front end. Microsoft thought that was a fine idea and built a lot of non-standard features to lock customers in. Vendors and corporate IT shops used those features to make their Web apps just like regular Windows apps – and users were locked in for good.

How will these users get out of this mess? When the time (and budget) is right, they'll jumpon the next big software development paradigm. They'll buy or build fresh, junk the old stuff completely and go about their business.

IT debt? They'll walk away from it. And why not? Those apps built on IE6 may be creaky, ugly and nonstandard, but they still work. And Microsoft may hate its nine-year-old miscalculation, but it has promised to keep supporting IE6 until 2014.

Besides, how much sense would it make to patch up those old clunkers or migrate them to newer browsers? None at all. Those old apps were designed for business needs from as much as a decade ago. Technical upgrades won't solve that. Building or buying new apps will – and doing that will cost the same, whether the apps they're replacing are up to date or ready to collapse.

The sensible thing is to keep running those IE6-dependent Web apps until they can be replaced with new apps that run from the cloud or on tablets or using whatever the hot new paradigm is.

The question in my mind here is whether the debt to which Hayes alludes refers to financial cost only. If so, he might have a point. But reading between the lines, I think the cost goes far beyond the financial to include opportunity cost. Hayes actually indirectly mentions opportunity cost by referring to continued use of old applications that address old business needs. He refers to present development cost, but not the cost of lost opportunity incurred over all the years since the associated software lost its relevance. That is the true technical debt.

(The quote that opens Hayes' essay is a classic: "We have to use IE6," a contractor at one telco told me recently. "We have all these Web applications that won't run on a browser that isn't broken.")