Software is abstract, but many concepts from the “real” world apply to software. We have all seen slapstick routines in which an actor carrying a board turns around and in so doing, slaps another actor with the board. In software terms, this would be a bug caused by a side-effect. When the actor turns around again and hits the victim with the other end of the board, perhaps we are reminded of a fix-to-a-fix that caused further problems. Locking our keys in the car corresponds to an “orphaned” buffer. Double returned buffers, or using a buffer after it has been released, correspond to why we have title searches and deeds for real estate.
Another useful analogy is the concept I call software debt. The assets and liabilities of a business fluctuate over time and modify its net worth. With software, the assets are related to how many lines of code are present with no outstanding liability. Our code is carrying a debt, a liability, if it has a lien against it in the form of patches that need to be updated in the source, or perhaps quick-and-dirty fixes that must be redone before further development can proceed. Therefore, we have the concept of “Do it right the first time.” Expedience is like a loan shark that charges exorbitant interest.
In the software life cycle, the ongoing costs of normal maintenance and improvements have historically been greater than developmental costs. I believe that part of these costs are the principal and interest accrued by deferred actions, or the software debt. Code reviews or inspections that were omitted, and patches or quick fixes that remain, will build up an implied debt that can bankrupt an organization that cannot keep up the interest payments.
Financial investments fluctuate in value as dividends and interest payments occur. The value of an airplane varies with its age (down until it becomes a collector’s item, then up), the total flying time on the airframe, the time since the annual inspection, and the time since major overhaul of the engine(s). These last two items, along with lack of compliance with airworthiness directives, are deferred costs like software debt. A plane with a fresh annual, low time since engine overhaul, and all airworthiness directives complied with has a much higher worth than one with these expenses pending.
In the case of software, code inspections are a “pay me now or pay me later” proposition. I prefer the friendly, normal hours scheduled work environment in contrast to emergency debugging sessions that amount to all-night code reviews and dumps and traces. Part of our methodology is the belief system that doing all the steps right is faster and more efficient in the long run. Just reacting to problems is like not maintaining all the bridges in a highway system, but just fixing the ones that collapse.
As products are transitioned between organizations (between the development house or to maintenance), an audit of the software debt can be used to evaluate a product. What is the state of documentation, conformance to standards, outstanding problems, patches, quick fixes, and any other deferred debts? A product should be kept in equilibrium so that it could be transferred immediately to another person or organization, without transferring an accompanying debt.
The “theory of the going concern” says “Don’t drain your assets to show a superficial profit or progress.” There are no shortcuts to a high-quality product. What are you doing to keep your software out of debt?
I wrote this article in 1991 for the Honeywell Technical Update Journal. Back then in assembly language programs, a “patch” was a patch to the executable file. It could be some code overlaying the original code or the original code could be patched to jump to a patch area reserved for adding code to the executable file. Current terminology is for a patch to be a whole executable unit or more, rather than a complete reinstall of a software package.
The current term for Software Debt is now the more general Technical Debt.
After I wrote this article, the Year 2000 (Y2K) problems appeared. Software does not rust, but the underlying context can change. Most programmers modified their code from using two-digit years to handle four-digit years, but some quick fixes solved the problem for 2000 but failed in 2001.