On Technical Debt

I recently had the opportunity to attend an on-line seminar conducted by none other than the venerable Steve McConnell, CEO and Chief Software Engineer at Construx Software. As a long-time admirer of Mr. McConnell’s work (Code Complete), I could not pass up a chance to hear him speak.

His topic was "Managing Technical Debt", referring to the software development costs associated with delayed technical work when short cuts are taken, or when planned features are eliminated or deferred, or when the short term expediency of low quality technical work is deemed acceptable.

As Fred Brooks (the much admired author of The Mythical Man-Month) observed many years ago: “On large teams, sub-teams tend to sub-optimize to meet their own targets rather than think about the total effect on the user. This breakdown in orientation is a major hazard of large projects.”  Mr. Brooks may have seen technical debt as a direct result of sub-optimization, and would certainly have included the ‘total effect on the user’ as part of the cost of assuming and carrying the debt.

As Mr. McConnell explained, in order for suboptimization to result in technical debt, it must entail some kind of expense or cost, and he suggested further that, if there is no cost associated with suboptimization, then it’s really not debt at all, and encouraged the listener to take on ‘zero interest’ debt, or debt with very low interest, or debt that need never be repaid.

At this point the entire concept of suboptimization as debt flirts with a dangerous rationalization that can be brutally costly to business operations; that is, the ’major hazard’ referred to by Mr. Brooks.

Simply put: there’s a big difference between a debt having no cost and having no cost to you. Can there be any incentive for the indebted to retire their debts, or any disincentive against taking on debts, if someone else is footing the interest bill?

I have heard it said many times: “IT made a bad decision years ago, and we’re still paying for it.” The users, who expected to accrue certain value from those deferred features or those suboptimized levels of function, will have to continue to operate at suboptimal levels, or worse, have to compensate by developing alternative methods, workarounds, or tactical solutions.  Forgone benefits can easily translate into ongoing costs, essentially the service on the technical debt, borne by the nothus miserum who is saddled with effects of someone else’s poor choice.

Mr. McConnell went on to suggest that, when a system is retired or replaced, any technical debt associated with it goes away as well. But, has the debt really gone if the debt service persists? Unless the new system eliminates the need for the manual workarounds and shadow systems that were build and maintained to compensate for suboptimization in the old, then those costs will continue long after the old system is gone.

The debt metaphor is a useful illustration, but the illusion of interest-free credit is a dangerous and potentially costly rationalization. The decision to suboptimize, and to take on technical debt, should be made with the 'total effect on the user' in full view.