The Technical Debt Metaphor: A Better Alternative
The concept of ‘technical debt’ has been receiving greater attention recently, in part due to the sub-prime mortgage crisis which has highlighted the dangers of excessively risky financial debt and the potential parallels with high risk software development practices (using code that hasn’t been tested properly).
For those who haven’t heard of it, technical debt is the argument that taking short cuts when developing software to hasten delivery time or avoid complexity is akin to taking on debt in that while a short term gain might accrue, at some point, the software will need to be re-written (or ‘re-factored’ in programmer parlance). In other words – the technical debt needs to be repaid just like financial debts.
Steve Freeman, writing on m3p.co.uk argues that technical debt is a flawed metaphor and that in some circumstances, debt can be viewed as positive and poor software may not always need to be replaced (unlike financial debts which are typically much harder to get out of). This makes it unsatisfactory for highlighting the potential risks of dubious code when explaining such issues to senior managers.
Instead he uses the “Call Option” to describe what happens with poor quality or untested code in financial terms. Writing a Call Option allows the issuer to charge a premium for allowing the right (but not obligation) to request an item at a pre-determined price at some stage in the future:
“Call options are a better model than debt for cruddy code (without tests) because they capture the unpredictability of what we do. If I slap in an a feature without cleaning up then I get the benefit immediately, I collect the premium. If I never see that code again, then I’m ahead and, in retrospect, it would have been foolish to have spent time cleaning it up. On the other hand, if a radical new feature comes in that I have to do, all those quick fixes suddenly become very expensive to work with. Examples I’ve seen are a big new client that requires a port to a different platform, or a new regulatory requirement that needs a new report. I get equivalent problems if there’s a failure I have to interpret and fix just before a deadline, or the team members turn over completely and no-one remembers the tacit knowledge that helps the code make sense. The market has moved away from where I thought it was going to be and my option has been called.” [Read More]
Share this Article: