Paying down the debt
A great term that I’ve just come across, technical debt is a metaphor coined by Ward Cunningham to reflect on how a decision to act expediently for an immediate reason may have longer term consequences. This is a classic problem during design and development where we have to balance various ‘quality’ factors against cost and schedule. The point of the metaphor is that this debt doesn’t go away, the interest on that sloppy or expedient design solution keeps on getting paid every time you make a change and find that it’s harder than it should be. Turning around and ‘fixing’ the design in effect pays back the principal that you originally incurred. Failing to pay off the principal? Well such tales can end darkly.
A great example of technical debt is the position that Toyota found themselves in with their spaghetti code monster, and of course one of the ways in which the interest can come due is in the form of design failures and accidents. In the worst technical debt is handled with what Aaron Erikson calls the Enron financing model of technical debt. Enron used to take very risky deals but would report only the wins on the main balance sheet while the losses were held on an ‘off balance sheet entity’ which (strangely) wasn’t reported to investors. For software this means that a software product is delivered at a certain price but also with lot’s of (invisible) technical debt on the ‘off balance sheet entity’ ledger. The answer is to insist on build and design standards that pay down such technical debt, rather than pay the interest during operation.
From a safety perspective technical debt can creep in when we start making undocumented and unvalidated assumptions about the system and it’s operational environment in order to save time and effort. A case in point would be the Ariane 501 disaster, here the software team decided to leave a floating point calculation unprotected and failed to remove un-needed code left over from Ariane 4. Combining the two with a different launch profile and you get ‘boom’.
The metaphor also provides a different perspective on software assurance standards.The goal of such standards may not just be to provide evidence of ‘goodness’, but to also to ensure that technical debt is paid down as low as possible before the software is fielded. For safety critical systems the interest on that technical loan can prove to be very high indeed.