In my previous writing you may have read about my views on the concept of Technical Debt. I think its too simplistic a concept that is used inappropriately and too often by my fellow software wranglers.

A few years ago I read Stephen Freeman’s blog post about Unhedged Call Options and it almost perfectly captured that extra nuance of detail I was trying to bring attention to… almost.

The detail that is missing from the Technical Debt concept is especially related to a dangerous asymmetry of concerns. It’s not uncommon to see the debate about Technical Debt heat up between the business team and the engineering team. The engineering team claiming to advocate reducing Technical Debt while accusing the business team of being the cause of it. The setup is that the engineering team is risking the survival of the business for the sake of what only they can judge as good code quality, while the business team is kicking the can down the road and thus setting the engineering up for a spectacular future disaster. With that picture in mind it is no surprise that the debate simmers down to one about Technical Debt; pay your dues now or pay them later with extra pain. But it’s absolutely not that simple. A Call Option analogy is much more applicable.

To better illustrate my point, let’s use a solid contemporary example we can relate to easily. Let’s say Tesla plans to sell 100 Model 3s to Uber for $30K each by the end of the year. That represents $3M in revenues. Tesla offers to sell a Call Option to Uber in early January. It essentially guarantees that Uber can buy the Model 3 throughout the year for no more than $30K each no matter what. That guarantee is the Call Option. 

For that guarantee that Tesla gives Uber, Uber pays Tesla a premium early in January. Let’s assume it’s 5% of the projected $3M so $150K. For Tesla, it means it makes an extra $150K regardless of Uber eventually buying those 100 Model 3s or not. It also means that Tesla gets an early infusion of cash critical to the early manufacture of the Model 3. For Uber, it means it gets to lock-in an upper limit to projected costs for a new fleet of 100 Model 3s. Its a win-win for all; if all goes well that is.

Tesla in this case isn’t getting the premium for free. It is in fact monetizing a bit of risk. If by mid year the cost of making the Model 3 becomes much more expensive, Tesla eats that cost. If the cost of making the Model 3 exceeds the profits per car Tesla would be loosing money on each car it sold to Uber under the Call Option agreement. There is no limit to the downside for Tesla. Let’s say batteries for the Model 3 suddenly cost $100K per car. Tesla would be obliged under the agreement to provide the cars to Uber for no more than $30K. A nightmare scenario.

Tesla can mitigate the risk of that nightmare scenario by putting in safeguards that hedge that risk. The degree to which Tesla goes to protect itself is totally up to Tesla. If Tesla, for example, decides not to keep a stock of Model 3s to cover Uber’s Option Call it would be an Unhedged or Naked Option Call.

This Call Option analogy adds much needed resolution to the debate. What I don’t agree with in Stephen’s article is the assertion of the headline. The headline implies that any implementation of a Call Option on code is creating “Bad code”. Maybe the MVP wasn’t a big thing back in 2010, but I bet “Bad code” was the label given to all MVPs at that time.

Technical Debt is making two invalid assumptions. One is that we know how the code should be done and the other is that we know it is the right code that will lead to a successful product. An MVP says “no, we don’t even know what the product really is to begin with and so we can’t make those assumptions”. So offering a Call Option makes much more sense since it offers flexibility essential to the survival of the business. And I really want to stress survival here. I’ve seen too many software engineers and system architects completely miss that point. You can insist on writing what you consider good code or you can pay the rent. You can’t expect to be able to do both all the time. You will inevitably run into that fork in the road and this article is all about getting you mentally ready to not only understand that you are in that situation, but also how to think about dealing with it.