9 ms·

Or we can not look at tech debt as debt but as a unhedged call option: http://higherorderlogic.com/2010/07/bad-code-isnt-technical-debt-its-an-unhedged-call-op

Or we can not look at tech debt as debt but as a unhedged call option: http://higherorderlogic.com/2010/07/bad-code-isnt-technical-debt-its-an-unhedged-call-option/ http://higherorderlogic.com/2010/07/bad-code-isnt-technical-... From the article: Call options are a better model than debt for cruddy code (without tests) because they capture the unpredictability of what we do. If I slap in an a feature without cleaning up then I get the benefit immediately, I collect the premium. If I never see that code again, then I’m ahead and, in retrospect, it would have been foolish to have spent time cleaning it up. On the other hand, if a radical new feature comes in that I have to do, all those quick fixes suddenly become very expensive to work with. Examples I’ve seen are a big new client that requires a port to a different platform, or a new regulatory requirement that needs a new report. I get equivalent problems if there’s a failure I have to interpret and fix just before a deadline, or the team members turn over completely and no-one remembers the tacit knowledge that helps the code make sense. The market has moved away from where I thought it was going to be and my option has been called.

mathattack 10y ago
I think you're right - it is very much like writing call options. It is still a liability, but of an unknown quantity.
ptype 10y ago
Honestly, this seems like a stretched comparison to me. How many managers understand options? And what is even the underlying for your call option? Why would it be a call option and not a put option?
- shoo 10y ago
  i think trying to explain in the language of options isn't a great comparison, perhaps a clearer way to think about it might be in terms of "robustness" to possible future scenarios (see also Taleb's Antifragile)
- eximius 10y ago
  I think it is more accurate but less useful.
- kafkaesq 10y ago
  That's precisely the point - the reason so many companies fall into the trap of technical debt is that they not only don't understand the risks of what they're getting into; they lack the language (and analogies) to describe the risks.
dwaltrip 10y ago
Totally agree. Unfortunately, it's a market with low liquidity and opaque fundamentals, so black magic reigns supreme. The greatest difficulty is trying to predict how the product will evolve, and thus how the software must also evolve. We should always be thinking about how the relevancy and requirements of each component of source code may change in the future: next month, in 6 months, 2 year from now, etc. To better evaluate the risk of each call option, there needs to be a strong, coherent, and tangible vision of what the product should be. This vision should be internalized by the entire team. There also needs to be a healthy, forward thinking dialogue between designers, product owners, and engineers.
rhizome 10y ago
Is there a concept like YAGNI at all in stocks/finance?
- dwaltrip 10y ago
  Buying stock in a company that is doomed to fail and end up with share price of $0. Saying "YAGNI" and not implementing the foobar component would be like choosing to not buy the stock.
- tim333 10y ago
  Minimise capex perhaps.
- deleted 10y ago
  [deleted]
shoo 10y ago
maybe "unhedged" here is the important bit. accumulated technical debt makes the software project less robust / less able to respond effectively to future events. there are many examples in life where failing to do maintenance / prepare for contingencies is a clear short/med-term win, provided something unexpected does not occur.
mscottford 10y ago
There are many different ways to describe this problem, and it's very possible that using a call option as a metaphor is a better fit. Unfortunately, "technical debt" is the term that's currently in fashion, so you at least have to mention it when you're suggesting an alternative approach. Incidentally, we're big fans of Martin Cronje's article[1] which suggests that "technical debt" is a broken metaphor, and he suggests using "depreciating assets" as an alternative. [1]: http://www.martincronje.com/technical-debt-is-broken/ http://www.martincronje.com/technical-debt-is-broken/
- 0xmohit 10y ago
  > and he suggests using "depreciating assets" as an alternative. Interesting. Maybe, the alternative should be "depreciating assets" + "appreciating liabilities".
  - perseusprime11 10y ago
    We already use depreciation in software when we start writing off capital allocation over time. This new metaphor maybe more confusing. I would rather stick with technical debt and give more context.
yelnatz 10y ago
I agree with this. Tech debt really is very similar to how selling call options work. Unfortunately, not a lot of people know how options work, so now you have another problem of explaining how that works.
crdb 10y ago
More like selling a put: you're hoping it expires out of the money, but if volatility goes up, it will be expensive. Upside is limited and short term, downside potentially unlimited and in the long term, so if your discount rate is high (due, perhaps, to low cash reserves) then the NPV of the trade still makes sense. People who sell a few puts get away with it for a while, but make it your business and you better be too big to fail. If everybody is selling puts and levering up, you better do it too or you'll find yourself out of a job. And if volatility increases, everybody is exposed at the same time so you won't get personally blamed anyway, and your career will be just fine.
- taeric 10y ago
  I think you are underselling the upside, to be honest. History is littered with massive successes that are essentially technical debt, as software folks call it. AC/DC power is actually a fun case study in that regard.
  - crdb 10y ago
    But the success is not directly inherited from technical debt. Technical debt bought time that enabled the success to happen (maybe before the company ran out of money, or allowing it to launch months ahead of the competition), but the company would not have failed if you somehow built it "properly" and otherwise met those constraints. In other words, you can rationally make the decision to take on technical debt if it allows you to meet those constraints. It isn't a black and white decision. It seems obvious to say this, but I know plenty of founders and investors who have had success (survivorship bias - if they hadn't they wouldn't be investors/founders) with the technical-debt-and-grow method and therefore apply it to every problem.
    - taeric 10y ago
      Any way you formulate this, it is entirely possible that taking on technical debt is required for a largely unbounded success. It may be a couple of steps removed, but it is still a direct line. Time to market is a vital metric for everyone. Anything that can help hit a tight time to market can add to the success of a company. Can you reformulate it so that time to market was irrelevant for success? Only if you are comfortable with what is likely a bad model.
mikekchar 10y ago
There is a problem with these metaphors: activities that work against technical debt are often dependent on the skill and experience of the programmers involved. You often get no long term benefit from doing them. I write code in a specific fashion, which involves a lot of TDD and a lot of refactoring. I've been doing it a long time and have refined it to the point where I expect to get payback in less than 1 week. But it is naive to expect that someone else will use the same techniques and achieve the same benefits right away (I have been, very, very naive in this respect at times :-( ). For example, non-mocking TDD forces a particular set of design decision to be made up front. It also forces the creation of specific API entry points. Mocking TDD allows you to defer design decisions and makes it cheap to explore large design spaces. It forces you concentrate on your interfaces. The choice of which to use in various situations dramatically affects how well you can refactor. With non-mocking unit tests, you can get buried in the details of setting up contexts. With mocking unit tests, you tests can become very brittle. It also allows/encourages you to make some pretty horrifying design choices. Even when people do TDD and have lots of tests, they often make poor choices and end up with code that they can't (or don't want to) refactor. The thing that people often do not understand is that unit tests and/or TDD will usually not provide much of a payback (in terms of productivity) alone. It is the refactoring that leads to simple design, reduces complexity, reduces code duplication, makes it easy to reason about changes, etc. Unit tests (and TDD in general) simply give you a framework for making refactoring easier. The problem, from my perspective, is not about judging risk of upfront payback versus long term payback. When done well, the activities around reducing technical debt pay off so quickly and so dramatically that there are almost no cases where they are inappropriate. The problem is that using the techniques poorly often leads to no payback at all! In fact, sometimes you inherit a project with a rat's nest of crazy tests and the first thing you do to improve your productivity is delete the tests -- on the principle that less code means less complexity that you need to deal with. Although my own personal style involves TDD and refactoring, I believe that the same can be said for other styles of development that are geared toward reducing technical debt. In my career I've done BDUP (1000 page requirement and design docs FTW!), I've done rapid prototyping (build 20 to throw away!), and a few other techniques. They can all work, but IMHO require even more skill to do well. This is one of the things I wish someone told me at the beginning of my career. At the moment my current feeling is that there are virtually no cases where tolerating/embracing technical debt will lead to even short term gains. However, the alternative is not straight forward. Young teams must expend considerable effort finding expertise to help guide them forward. More importantly, everybody on the team needs to be aligned to the style that will be used. How you achieve that alignment is yet another can of worms.

mathattack 10y ago

I think you're right - it is very much like writing call options. It is still a liability, but of an unknown quantity.

ptype 10y ago

Honestly, this seems like a stretched comparison to me. How many managers understand options? And what is even the underlying for your call option? Why would it be a call option and not a put option?

shoo 10y ago
i think trying to explain in the language of options isn't a great comparison, perhaps a clearer way to think about it might be in terms of "robustness" to possible future scenarios (see also Taleb's Antifragile)
eximius 10y ago
I think it is more accurate but less useful.
kafkaesq 10y ago
That's precisely the point - the reason so many companies fall into the trap of technical debt is that they not only don't understand the risks of what they're getting into; they lack the language (and analogies) to describe the risks.

dwaltrip 10y ago

Totally agree. Unfortunately, it's a market with low liquidity and opaque fundamentals, so black magic reigns supreme. The greatest difficulty is trying to predict how the product will evolve, and thus how the software must also evolve. We should always be thinking about how the relevancy and requirements of each component of source code may change in the future: next month, in 6 months, 2 year from now, etc. To better evaluate the risk of each call option, there needs to be a strong, coherent, and tangible vision of what the product should be. This vision should be internalized by the entire team. There also needs to be a healthy, forward thinking dialogue between designers, product owners, and engineers.

rhizome 10y ago

Is there a concept like YAGNI at all in stocks/finance?

dwaltrip 10y ago
Buying stock in a company that is doomed to fail and end up with share price of $0. Saying "YAGNI" and not implementing the foobar component would be like choosing to not buy the stock.
tim333 10y ago
Minimise capex perhaps.
deleted 10y ago
[deleted]

shoo 10y ago

maybe "unhedged" here is the important bit. accumulated technical debt makes the software project less robust / less able to respond effectively to future events. there are many examples in life where failing to do maintenance / prepare for contingencies is a clear short/med-term win, provided something unexpected does not occur.

mscottford 10y ago

There are many different ways to describe this problem, and it's very possible that using a call option as a metaphor is a better fit. Unfortunately, "technical debt" is the term that's currently in fashion, so you at least have to mention it when you're suggesting an alternative approach. Incidentally, we're big fans of Martin Cronje's article[1] which suggests that "technical debt" is a broken metaphor, and he suggests using "depreciating assets" as an alternative. [1]: http://www.martincronje.com/technical-debt-is-broken/ http://www.martincronje.com/technical-debt-is-broken/

0xmohit 10y ago
> and he suggests using "depreciating assets" as an alternative. Interesting. Maybe, the alternative should be "depreciating assets" + "appreciating liabilities".
- perseusprime11 10y ago
  We already use depreciation in software when we start writing off capital allocation over time. This new metaphor maybe more confusing. I would rather stick with technical debt and give more context.

yelnatz 10y ago

I agree with this. Tech debt really is very similar to how selling call options work. Unfortunately, not a lot of people know how options work, so now you have another problem of explaining how that works.

crdb 10y ago

More like selling a put: you're hoping it expires out of the money, but if volatility goes up, it will be expensive. Upside is limited and short term, downside potentially unlimited and in the long term, so if your discount rate is high (due, perhaps, to low cash reserves) then the NPV of the trade still makes sense. People who sell a few puts get away with it for a while, but make it your business and you better be too big to fail. If everybody is selling puts and levering up, you better do it too or you'll find yourself out of a job. And if volatility increases, everybody is exposed at the same time so you won't get personally blamed anyway, and your career will be just fine.

taeric 10y ago
I think you are underselling the upside, to be honest. History is littered with massive successes that are essentially technical debt, as software folks call it. AC/DC power is actually a fun case study in that regard.
- crdb 10y ago
  But the success is not directly inherited from technical debt. Technical debt bought time that enabled the success to happen (maybe before the company ran out of money, or allowing it to launch months ahead of the competition), but the company would not have failed if you somehow built it "properly" and otherwise met those constraints. In other words, you can rationally make the decision to take on technical debt if it allows you to meet those constraints. It isn't a black and white decision. It seems obvious to say this, but I know plenty of founders and investors who have had success (survivorship bias - if they hadn't they wouldn't be investors/founders) with the technical-debt-and-grow method and therefore apply it to every problem.
  - taeric 10y ago
    Any way you formulate this, it is entirely possible that taking on technical debt is required for a largely unbounded success. It may be a couple of steps removed, but it is still a direct line. Time to market is a vital metric for everyone. Anything that can help hit a tight time to market can add to the success of a company. Can you reformulate it so that time to market was irrelevant for success? Only if you are comfortable with what is likely a bad model.

mikekchar 10y ago

There is a problem with these metaphors: activities that work against technical debt are often dependent on the skill and experience of the programmers involved. You often get no long term benefit from doing them. I write code in a specific fashion, which involves a lot of TDD and a lot of refactoring. I've been doing it a long time and have refined it to the point where I expect to get payback in less than 1 week. But it is naive to expect that someone else will use the same techniques and achieve the same benefits right away (I have been, very, very naive in this respect at times :-( ). For example, non-mocking TDD forces a particular set of design decision to be made up front. It also forces the creation of specific API entry points. Mocking TDD allows you to defer design decisions and makes it cheap to explore large design spaces. It forces you concentrate on your interfaces. The choice of which to use in various situations dramatically affects how well you can refactor. With non-mocking unit tests, you can get buried in the details of setting up contexts. With mocking unit tests, you tests can become very brittle. It also allows/encourages you to make some pretty horrifying design choices. Even when people do TDD and have lots of tests, they often make poor choices and end up with code that they can't (or don't want to) refactor. The thing that people often do not understand is that unit tests and/or TDD will usually not provide much of a payback (in terms of productivity) alone. It is the refactoring that leads to simple design, reduces complexity, reduces code duplication, makes it easy to reason about changes, etc. Unit tests (and TDD in general) simply give you a framework for making refactoring easier. The problem, from my perspective, is not about judging risk of upfront payback versus long term payback. When done well, the activities around reducing technical debt pay off so quickly and so dramatically that there are almost no cases where they are inappropriate. The problem is that using the techniques poorly often leads to no payback at all! In fact, sometimes you inherit a project with a rat's nest of crazy tests and the first thing you do to improve your productivity is delete the tests -- on the principle that less code means less complexity that you need to deal with. Although my own personal style involves TDD and refactoring, I believe that the same can be said for other styles of development that are geared toward reducing technical debt. In my career I've done BDUP (1000 page requirement and design docs FTW!), I've done rapid prototyping (build 20 to throw away!), and a few other techniques. They can all work, but IMHO require even more skill to do well. This is one of the things I wish someone told me at the beginning of my career. At the moment my current feeling is that there are virtually no cases where tolerating/embracing technical debt will lead to even short term gains. However, the alternative is not straight forward. Young teams must expend considerable effort finding expertise to help guide them forward. More importantly, everybody on the team needs to be aligned to the style that will be used. How you achieve that alignment is yet another can of worms.