Bad code isn’t technical debt, it’s an unhedged call option

What would the engineering equivalent of that be, I wonder?

Quitting and getting hired back as a consultant?

With tech projects there's almost always a de facto "abandon" option – if not for the firm then at least for the individual engineers. So whenever the cost of proceeding is higher than the expected value, you exit. That clips the downside, more like some sort of combined option position.

Or more like a specific kind of debt: nonrecourse loans secured by collateral. You get the money up front, but if it proves impossible to repay, you simply surrender the collateral. In this case, the collateral is the project itself: either the option to continue, or the IP rights, or the enclosing firm. And, in the event of failure, those may be worth nothing, so you aren't losing an unbounded amount.

For monetary debt, these fragmentary artifacts may in fact be surrendered to the creditors. In the case of metaphorical technical debt, you surrender up those hopes and dreams and mental (sunk) costs, to the reality that there won't ever be the time and budget to fix the system.

And so this leads to a different conclusion than the article, which ends with a near-religious stance against the inflexible evil of debt. Because the downside – project abandonment – is capped, sometimes technical debt is worth taking on, when acceleration-to-market (and thus market-feedback-learning) is of paramount importance. You're borrowing from the future, but you only pay it back (with interest) if there's wild success. If you fail for any other reason – perhaps things having nothing to do with the technical debt – you don't have to pay it off, you just surrender the (essentially worthless) collateral.

That's a hard thing for people with an aesthetic or craftsperson mentality to accept. And it still sucks when it's the technical debt itself – the cost of fixing old rushed choices – that occasionally makes a project no longer competitively viable. Your monetary credit report is unblemished, but your self-conception can take a hit.

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.

Premature optimization is the root of all evil (or at least most of it) in programming.

The problem of making something worth maintaining has priority...and the software upon which it depends is often a second or third order priority. Facebook was built on PHP. That using PHP created technical debt was a nice problem to have on the way to the bank. None of which is to say that writing bad software is ok. It is to say that bad software includes software that wastes time trying to anticipate and solve the wrong problems at the wrong time for the sake of an ideal rather than current business needs.

What I've actually seen in practice is that "technical debt" mostly means "things I wouldn't have written that way." It has very little to do with the code and more to do with the philosophical leanings of the commenter.

Selling a naked put - Integrating a 3rd party library for a feature vs building it yourself. Immediate benefits, and probably unlikely to go sideways, but if the framework turns out to suck you suddenly incur a large unexpected body of pain. However, unlike a naked call, there's understood limited downside, limited to the functionality the library provides.

Buying a put - Building in any kind of protection from "very low probability but high damage" events, such as provisioning a completely separate infrastructure in the case of a massive DC or network outage, or having a completely separate monitoring system in case the first goes down in the middle of fighting a separate fire.

Buying a call - Basically anytime you make an engineering bet that costs a bit of time and is unlikely to pan out but if it does, you win big. Like a spike to try some state of the art algorithm or bringing on a short term consultant to solve a really hard problem. If your whole team is always doing these in the long run you lose, but strategically doing these when they make sense in the long run can result in huge gains.

Selling a covered call - Focusing on consulting services vs building a product. Steady income, but in the unlikely case you build something that strikes gold, it won't be you who becomes rich overnight, it's the person who paid you to build it.

You can build a shanty village without a plan that supports a million people, but the first fire, storm, earthquake, etc destroys the whole thing. Also, for some reason when Bob flushes his toilet, the power goes out briefly in the capitol building. Nobody knows why, but routing power through the sewer last sprint to save time probably wasn't a good idea.

But anyway, I agree - naked call options is a much more accurate term. But it is a difficult term for folks to get their heads around (incurring debt is something the post Marx Brothers world has gotten used to. Outside specialised areas of finance, not so much with Options)

Comparatively very few people have a useful intuition about "unhedged call options" that using it as a metaphor for poor code quality would leverage.

Also, I think predictable ongoing support cost is a big result of poor code quality in production systems, so that aspect of the debt metaphor isn't completely off-base (there are also unpredictable potential costs in the future, as well, so its not a perfect analogy.)

So I think it needs to be judged in context - who are we trying to communicate with?

Well, not really. For example, if you took usd-based debt in russia, you are now quite royally fucked.

Explaining that doing things "bad" creates "technical debt" or "unhedged call options" I think sets us up for not being taken all that seriously because these things themselves are abstractions that we have to work hard to reason about effectively.

Is it more useful if we say something tangible--that programming is like working on a house? Imagine you just started working on updating a house last month. The owner comes to you with a request that they be able to see what's going on in the kitchen from the living room; you _could_ just knock a hole in the wall. That would satisfy the basic requirements, but it's going to make a mess, it's going to look like shit, and it may disrupt the electricity/plumbing/hvac or even the stability of the house itself. But even if we make a proper window or door between the rooms without disrupting other systems in the house and clean up our mess, it's still possible we make a door or window that is a little different than all of the other doors and windows the past builders have put in the house.

In 2 or 10 or 20 years, after several maintainers have come and gone, the owner discovers that they're being bled dry by the house's energy inefficiency. The new maintainer may go measure a window twice and get the dimensions down precisely and then count all of the windows in the house that look the same. Then they go place an order for N new energy-efficient windows. When the windows arrive and they're getting ready to replace them, they come to the terrifying realization that every window in the house is actually custom, and only a few of the windows will fit. They install the windows that fit and try to return the others only to find out the vendor charges a healthy restocking fee. Down 40% of our budget for replacing the windows but only having actually replaced 15% of them, we no longer have enough money to replace the rest. The owner decides to just use the remaining 60% to cover the increased energy costs instead of fixing the issues.

The new maintainer goes to put the diagonal blinds back up on the windows that did get replaced and discovers the custom mounting hardware has gone missing in the shuffle, so the blinds get left in the corner with a note that someone needs to find a way to put them back up when there is time and money. It's the middle of the winter anyways; the sun is always under the horizon when the owners are home. Because this is a _funhouse_, these were of course the blinds with the greatest role in reflecting summer heat, and despite the improved window technology, total energy efficiency is going to be in the shitter come summertime. For now, perhaps quixotically, energy efficiency is buoyed by the extra solar heat; the owner seems happy enough with the updates, and the metrics all show good performance.

Houses need maintenance. Things on or in them break and can't be fixed because either the parts aren't made that way anymore or the knowledge of how to fix it has eroded. They end up with empty telephone nooks and doors that were sheet-rocked over instead of being removed. A major appliance stops working and you discover the house needs infrastructure updates before a contemporary version of the same can be installed. The maintainers want to add a floor and some new rooms and they need an architect and an engineer to make sure they aren't going to ruin the roof line, slab or overload a wall. Down the road it will have different rooms built in the fashion of three decades over a span of 80 years. Further down the road a room will get sealed off when the roof caves in and the owner doesn't have the funds to fix it.

Code quality problems are, as expressed in the OP, an unknown unknown. It's rare that anyone has a handle on just how bad things are, until it's too late. Also, there are sociological issues with legacy rescue projects that businesspeople, who'd rather think of programmers as fairly interchangeable, don't like to contend with: maintenance is only effective if done by high-quality programmers, but it's expensive and often hard as hell to motivate good people to do it. A pat on the back and a 10% bonus won't do it, because it doesn't come close to offsetting the career costs of doing undesirable work.

There is an apocryphal story about a trader buying chocolate santa futures and forgetting to sell them on. Eventually a truckload turned up at the Wall Street headquarters.

This has little to do with the subject itself, but this has actually happened, sort-of. Futures contracts usually don't include Wall Street as a delivery location, so it's not like the trader ends up taking physical delivery at the workplace. The contract will specify where one must make or take delivery, and most delivery locations are in the Midwest or Plains.

When a trader fucks up and has to make or take delivery, there are services that handle it, but it's expensive. If you get stuck taking delivery of, say, $500,000 worth of butter, you'll probably have to pay the agency 50 cents on the dollar, or $250,000, to handle the task of getting your surplus butter to a wholesaler. It hurts pretty bad.

I also think that the call option is a bad analogy for similar reasons. In a call option you could be obliged to pay out. You never have to pay out with code. You can decide to get your developers to write code or not write code. No bailiffs will come knocking on the door.

Technical drag coefficient may be a better analogy.

For a car, the drag force increases as you speed increases.

For code, the more features you want to add, bug you want to fix, etc. (i.e. the bigger your velocity) the more the TDC will kick in to slow you down. It may put a speed limit entirely on what you can do until you put work in to reduce it.

Also you can write-off the car and invest in a new one. I have seen this many times of course - the 'new product' that is written that won't have all of the problems of the last one.

Moreover, in a startup context, both metaphors break down: you can walk away from your technical debt by shutting down. You can't walk away from your financial debts (or call option shorts) so easily.