Bad code isn’t Technical Debt, it’s an unhedged Call Option

By Frances Lash On December 29, 2014 At 9:05 am

This is a post that discusses an alternative to the metaphor of technical debt for ‘bad code’. The problem with technical debt as a metaphor is that for managers debt can be a good thing – it can required for financial needs or encouraged by tax breaks in certain financial situations. However, the debt that is often spoken about in codebases does not fully capture the risk that comes along with writing short cuts.

Maybe the better metaphor would then be a call option. A call option is when the right, not the obligation, is sold to someone to buy an agreed on quantity of something at a price that is fixed now. From the seller perspective, if the price stays to low they get to keep the payment and are ahead but they also run the risk of still having to provide the good even when the price has increased greatly. This is can be referred to as an unhedged call – where no matter what the a product costs to the seller they have to supply it.

Call options is a better model for code issues because it captures the unpredictability of what can happen when writing in certain features and code. For example, a feature can be added to a system without cleaning it up and the benefit is collected immediately (the premium is collected). If that code is never called upon again than it would have been foolish to clean it up in the first place. However, lets say a radical new feature is going to added – these quick fixes and become very expensive to deal with. Time has to be taken to fix these issues right before deadline or no one on the team remembers pertinent information need for the code to make sense in the first place – the market by then has moved away from where it was expected to be and the option has been called. No matter what the cost to input this feature it must be delivered.

Therefore, even if it is more expensive to do thing clean from the start, it would also be less risky. A messy system is full of unhedged calls that can be called upon at an unpredictable cost to the organization. Technical debt does not communicated the risk of writing sloppy or quick fixes into code – debt is something to be managed and just another tool. When talking about implausible delivery dates it may make more sense to talk about unhedged call options.

To read the full post go to: http://nblo.gs/12c3vP

FREE Report: How to Monetize Application Technical Debt — Gartner & CAST
A Data-Driven Approach to Balance Delivery & Agility with Business Risk

Technical Debt has been growing exponentially as maintenance is starved and development teams are forced to cut corners to meet increasingly unrealistic delivery schedules. CAST clearly defines Technical Debt so it can be measured and then juxtaposed with the business value of applications to inform critical tradeoff between delivery agility and business risk.

Your Information will be kept private and secure.

Add your comment

XHTML : You may use these tags : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

This is a Gravatar-enabled website. To get your own globally-recognized avatar, please register at Gravatar.com