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

by

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

Filed in: Technical Debt
  This report describes the effects of different industrial factors on  structural quality. Structural quality differed across technologies with COBOL  applications generally having the lowest densities of critical weaknesses,  while JAVA-EE had the highest densities. While structural quality differed  slightly across industry segments, there was almost no effect from whether the  application was in- or outsourced, or whether it was produced on- or off-shore.  Large variations in the densities in critical weaknesses across applications  suggested the major factors in structural quality are more related to  conditions specific to each application. CRASH Report 2020: CAST Research on  the Structural Condition of Critical Applications Report
Open source is part of almost every software capability we use today. At the  very least libraries, frameworks or databases that get used in mission critical  IT systems. In some cases entire systems being build on top of open source  foundations. Since we have been benchmarking IT software for years, we thought  we would set our sights on some of the most commonly used open source software  (OSS) projects. Software Intelligence Report <> Papers
Making sense of cloud transitions for financial and telecoms firms Cloud  migration 2.0: shifting priorities for application modernization in 2019  Research Report
Load more reviews
New code
|
()