While I agree with the overall message in this article, "unhedged call option" is not a phrase most people will get. "technical debt" is much easier to understand. "technical gambling" might be better, though i realize not as accurate as "call option".
the term "technical debt" is fairly clear; "technical credit" or 'technical lending" is fuzzier but also more descriptive. Maybe the compromise is "technical debt with interest"
actually, "technical trading" might be a good contender too. You might make out in the long run, or crash and burn. It's all about trade-offs anyway; not writing tests now means future you will have to write them. Sometimes this is fine, sometimes this is a truly horrible idea, and sometimes it could go either way.
I agree with you that "unhedged call option" is not a phrase most people will get, on the other hand software engineering needs a better vocabulary around tech debt. There is a very specific type of tech debt that I think this describes
So if you think we need better differentiation of technical debt (which I do) then finance is a good source of those differentiations[1]
Personally I've heard tech debt used to describe everything from tightly coupled UI/DB code, to design decisions the person disagreed with, to code without tests. Even though those are obviously 3 different problems. So I'm for increasing the size of our vocabulary
Why does it matter that "most" people don't get it. If we call an array a hash, that might be a more well known term, yet if it's innaccurate, what difference does it make? It's the wrong term. Using the wrong term to describe something simply because the wrong term is more well known doesn't make it a better term to use. As I mentioned in another comment, it isn't the term itself that matters, what matters is the meaning. "Technical debt" is the wrong paradigm because of the simple fact that it doesn't always have to be repaid and in fact making that "investment" could result in a higher return if it doesn't have to be repaid. Of course, it could result in a much lower return if it has to be repaid. With debt, you have a known interest rate and upfront, you are aware of the future cost. However, with technical debt we never know the future cost; thus the debt analogy is completely innaccurate.
And technical trading as a term is just completely wrong because the term technical trading already has a meaning; and it has nothing to do with understanding the unknown future benefit or gain. It has to do with making decisions (and predictions) based in extrapolating past results into the future. If anything we should be calling it fundamental trading since fundamental trading is making investment decisions based on a holistic view of the security in question. So, the decision to incur a technical "debt" is made with an understanding of the entire system and the cost-benefit analysis of paying "cash" now versus paying an unknown amount of cash later -- or not having to pay anything at all.
One could call it gambling, but a more accurate description would be risk management. Using a risk management decision matrix one could say that the risk of someone dying in a flood at a shopping mall would be catastrophic, however the likelihood is exceptionally low, so it wouldn't make sense to have life boats spaced every 10 meters. However, it could happen, but the shopping mall owner chose to incur that "debt" of not having lifeboats because they determined that the cost wasn't justified given the profile of the risk. A debt analogy would say that a shopping mall absolutely will be flooded eventually and the debt would exist until such day that the owner bought lifeboats.
The purpose of an analogy is to educate a concept using an approximation of another concept the person will understand. If the person in charge of risk management doesn't understand how risk accumulates in a codebase, they're far more likely to understand the model of technical debt than options calling.
the term "technical debt" is fairly clear; "technical credit" or 'technical lending" is fuzzier but also more descriptive. Maybe the compromise is "technical debt with interest"
actually, "technical trading" might be a good contender too. You might make out in the long run, or crash and burn. It's all about trade-offs anyway; not writing tests now means future you will have to write them. Sometimes this is fine, sometimes this is a truly horrible idea, and sometimes it could go either way.