Bad Code Isn’t Technical Debt, It’s an Unhedged Call Option • Hacker News Board

Re: Bad Code Isn’t Technical Debt, It’s an Unhedged Call Option

#11

Post by grandalf » Fri, Jul 23, 2010, 9:02 PM UTC

raganwald wrote: post #5

grandalf wrote: post #3

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.

"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,…

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.

Re: Bad Code Isn’t Technical Debt, It’s an Unhedged Call Option

#12

Post by jcl » Fri, Jul 23, 2010, 9:20 PM UTC

MarkBook wrote: post #10

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.

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.

Re: Bad Code Isn’t Technical Debt, It’s an Unhedged Call Option

#13

Post by byrneseyeview » Fri, Jul 23, 2010, 9:20 PM UTC

MarkBook wrote: post #10

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.

A naked put works better.

Re: Bad Code Isn’t Technical Debt, It’s an Unhedged Call Option

#14

Post by steveplace » Fri, Jul 23, 2010, 9:32 PM UTC

dthakur wrote: post #2

"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.

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.

Re: Bad Code Isn’t Technical Debt, It’s an Unhedged Call Option

#15

Post by steveplace » Fri, Jul 23, 2010, 9:36 PM UTC

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.

Re: Bad Code Isn’t Technical Debt, It’s an Unhedged Call Option

#16

Post by raganwald » Fri, Jul 23, 2010, 9:57 PM UTC

grandalf wrote: post #11

raganwald wrote: post #5

Earlier quoted context omitted.

"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,…

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 s…

Well, returning to the OP, selling a call short does not automatically mean you lose money. It's just that once in a while you are exposed to losses that far outweigh the price of the call.

So perhaps the Dick and Jane example is one where you are ahead of the game by leaving the code as is and only refactoring it later when needed.

It does take real skill to forecast what is needed and what isn't, we 100% agree on that :-)

Re: Bad Code Isn’t Technical Debt, It’s an Unhedged Call Option

#17

Post by grandalf » Fri, Jul 23, 2010, 10:14 PM UTC

dbshapco wrote: post #7

grandalf wrote: post #3

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.

My experience is the opposite. The simplest solution is harder and takes longer. I think easiest or quickest is what is really meant in this formulation, but rarely do either of these result in simplest. I start with the former and strive to iterate towards the latter, because the former starts cheaper but ends up more expensive in the long run. Simplification is an optimization.

Perhaps, but businesses are not run on the basis of the long run (unless you are in R&D mode for 10 years), they are one short run after the next.

Re: Bad Code Isn’t Technical Debt, It’s an Unhedged Call Option

#18

Post by colin242 » Fri, Jul 23, 2010, 10:29 PM UTC

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.

Re: Bad Code Isn’t Technical Debt, It’s an Unhedged Call Option

#19

Post by arthurdent » Fri, Jul 23, 2010, 10:42 PM UTC

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.

Re: Bad Code Isn’t Technical Debt, It’s an Unhedged Call Option

#20

Post by btilly » Fri, Jul 23, 2010, 10:47 PM UTC

grandalf wrote: post #11

raganwald wrote: post #5

Earlier quoted context omitted.

"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,…

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 s…

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.)