

Bad Code Isn’t Technical Debt, It’s an Unhedged Call Option - thekguy
http://www.m3p.co.uk/blog/2010/07/23/bad-code-isnt-technical-debt-its-an-unhedged-call-option/

======
ericflo
The "Error establishing a database connection" I'm getting on this link is
incredibly ironic.

~~~
jrockway
You are confusing bad software with technical debt. Debts can be paid off.
Wordpress can only be burned to the ground and never mentioned again.

------
dthakur
"Short call" might be a better phrasing than "writing unhedged Call Option".

When someone mentions "unhedged Call Option" (as in the title), it usually
means long call, not short call.

~~~
steveplace
Technically, a long call means you're hedged to the downside, and you payed a
premium to protect yourself. Those that consider long calls unhedged are
usually trading around a complex position (vertical or calendar spreads).

It's not often I get to dump my option geekery on hn.

------
colin242
One big difference between owning sloppy code and issuing a risky stock
contract is that the stock contract comes due on a certain date, which is
known in advance. Sloppy code is much harder to manage because we never know
when we will be called to account for it. Like debt, code sticks with you
until you pay it down or go bankrupt.

Maybe it's more accurate to say that automated tests, refactoring, and other
code quality measures are forms of insurance against future requirements
changes.

------
MarkBook
I think technical debt is a much better metaphor than the unhedged call option
one. That's unnecessarily complex and worse, it's less accurate. The downside
isn't unlimited as he suggests, there is a well defined limit, 0 sales.

~~~
jcl
I think the unhedged call is a better metaphor. The stuff you gain by writing
sloppy code is not sales but saved development time. The potential downside is
the development time spent debugging or updating the system.

The lost development time is bounded by the cost of reimplementing the system
correctly, which is theoretically infinite (assuming a non-zero chance of
error each time you reimplement it). But in practical terms it is merely
expensive -- potentially more expensive than you can afford -- just like the
financial case.

~~~
bmm6o
Regardless of which metaphor is a more accurate translation, "technical debt"
is much more accessible. If you have to explain your turn of phrase, it's not
going to catch on.

------
steveplace
Stock options and other derivatives essentially play off two things: risk and
premium. If the premium is much higher than what you think the actual risk is,
then you need to sell it; vice versa for a higher risk.

I understand where the OP is coming from, although you have to have a little
background knowledge in the area. He points out that sometimes you will have
events in which you mispriced the risk-- in other words, the theoretical
premium you received was not worth the risk.

A much more interesting discussion would be how you would quantify this risk
and decide when and where sloppy code will work.

------
arthurdent
sort of silly to try to keep the metaphor as a financial instrument.

its really a simple message: write bad code, and you might pay for it later.
sometimes you get lucky, sometimes you don't.

"technical debt" as a term isn't intended to capture a specific risk/reward
payout structure. It doesn't need clarification in this vein.

------
grandalf
Unless you're being paid by the hour or don't care when the product ships,
it's always a good idea to just to the simplest implementation that works.

Premature prevention of technical debt is the root of all evil.

~~~
raganwald
"The simplest implementation that works" is not the antithesis of "Code
without technical debt." For example, code that has not been thoroughly tested
can not be said to "work." Likewise, one form of technical debt is code that
is not the simplest possible implementation. For example, Dick and Jane each
implement their own versions of the same functionality, producing code that is
not DRY. This has local simplicity, because Dick and Jane did not need to
coördinate their implementations, but it does not have global simplicity.

"Premature prevention of technical debt is the root of all evil."

If you are wittily comparing the reduction of technical debt with
optimization, I am confused. Optimization often increases technical debt by
adding complexity, so "premature" optimization is a little like buying a call
option rather than selling one. The word "premature" gives us an out, of
course, but overall I would say that optimization and the reduction technical
debt are not isomorphic.

~~~
grandalf
Those are fair points and I think that the example you use with Dick and Jane
is a good one:

Suppose Dick and Jane both implement their simple feature which is fairly
similar. I'd estimate that much of the time it's costless to have two slightly
different approaches in the codebase. In those cases it's also nearly costless
to retroactively standardize.

In the remaining cases where it isn't costless to retroactively standardize, a
better optimized abstraction would have been useful. But, depending on the
product's life cycle, building that abstraction may or may not count as
premature optimization. Suppose Dick's feature takes off but Jane's ends up
being phased out, now the extra month building the abstraction was totally
wasted.

Is that technical debt a big leveraged call option that could cripple the
team/org? Maybe, but maybe not. Maybe it's just a hassle that needs to be
borne only if the feature succeeded, and thus would have been premature
optimization if the feature didn't succeed. In other words exploration vs
exploitation and the risk of cementing possibly unneeded conceptual overhead.
I guess my intuition is that premature optimization comes from attempting in
advance to pave the way for a low technical debt future on an unknown feature
horizon.

It takes real skill to avoid this if one is too attuned to technical debt
elimination as a design goal.

~~~
btilly
_Suppose Dick and Jane both implement their simple feature which is fairly
similar. I'd estimate that much of the time it's costless to have two slightly
different approaches in the codebase. In those cases it's also nearly costless
to retroactively standardize._

My experience disagrees on both counts. Furthermore my experience is that if
I'm actively developing code and feel that a particular piece of cleanup is a
good idea, the usual time to my discovering that it really _was_ a good idea
is about 2 weeks. (In maintenance it proves itself much more slowly.)

Of course I have quite a bit of experience and a well-trained intuition. I've
seen other people whose "cleanups" were anything but, and who were fond of
entering abstractions to simplify the future that would never pay off. (I'm a
big believer that making something simple with little code makes virtually any
future rewrite easier. This helps. A lot.)

------
nphase
Cool! So the real question is, can I bundle a bunch of technical debt into a
CDO and sell it to some rich sucker?

