Ignore Technical Debt and Focus on the Hedge Instead.

In my previous writing you may have read about my views on the of Debt. I think it’s too simplistic a concept that is used inappropriately and too often by my fellow software wranglers. concept Technical A few years ago I read Stephen Freeman’s blog post about and it almost perfectly captured that extra nuance of detail I was trying to bring attention to… almost. Unhedged Call Options 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. Tesla and Uber 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. It’s 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 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 Option Call. hedge Unhedged or Naked To Ship or Not to Ship In software, the decision to ship what engineering would consider less than ideal software for short-term gains is like offering a Call Option. We are asking to receive an early premium by shipping now and promising to deliver the full product later. Hedging our Call Option then becomes a matter of how much effort we put in the software architecture to be able to deliver on our promises later. We begin to highlight the art of balancing tradeoffs that defines real entrepreneurs. Think of the MVPs 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 wasn’t a big thing back in 2010, but I bet “Bad code” was the label given to all MVPs at that time. MVP 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 of the business. And I really want to stress 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. survival survival It’s a Technical Hedge The nightmare scenario of course is that you don’t build the perfect code, as far as you’re concerned, and you end up with a costly mess in the future. Possible? sure. Probable? …ehh. How sure are you that what you’re trying to bring to perfection is the ultimate solution that demands so much sacrifice to begin with? If we come to that level of understanding, then at that point maybe we can move the debate to how much we need to back our Call Option. By that I mean making choices in the present that, as much as possible, allow for the best outcome. Taking advantage of a premium that serves to make for greater chances of success in the long run. Think of it as building a learning architecture. So instead of focusing on trying to build every feature that you could possibly run into, focus on an architecture that is designed to learn, adapt, and evolve instead. Technical Hedge