3 ms·

This article repeats a meme, but is total BS. It's similar to saying "the hidden costs of being a founder" and then stating that if you do ever make a successf

This article repeats a meme, but is total BS. It's similar to saying "the hidden costs of being a founder" and then stating that if you do ever make a successful exit, you will have a lot of your time wasted by having to select bedlinen and other hidden costs of having made an exit. (the hidden cost to being a founder - you will be forced to work unpaid hours shopping for luxury bedlinen. so consider carefully.) Well guess what: that's not real technical (or founder) debt! The idea of calling this stuff technical debt is simply laughable. there's no debt. you don't owe shit. hint: if you code something up in 20 minutes you still don't have to do all that other stuff, you can just ignore it, and throw away the twenty minutes of code if it's not better than not having it. if you become a millionaire you don't have to do all that stuff, you can just ignore it. Let me put it another way. Say you're an MBA who can't code anything but excel formulas, yet you figured out how to get excel and powerpoint onto the web as a web app (wat). you create something and get 5,000 paying users and raise a $500,000 investment. Have you created technical debt? No. You're at the same square as if someone gave you $500,000 to spend on developers against your mockups, except that you've validated them as well. There's no debt here. This article had it right: http://www.higherorderlogic.com/2010/07/bad-code-isnt-technical-debt-its-an-unhedged-call-option/ http://www.higherorderlogic.com/2010/07/bad-code-isnt-techni... The people that call this scenario (excel on the web) technical debt, think that somehow the MBA 'borrowed' the web app from a real dev, and now owes it in real development costs. That's a wrong way to think about it. In fact it's a ridiculous way to think about it.

aba_sababa 12y ago
And then your teammate then takes a week to build an API that's only compatible with your hacked out code you wrote in twenty minutes. Now you've wasted both your time and her time when both need to be re-written.
- logicallee 12y ago
  Yes, consider what has happened here carefully. Maybe she shouldn't be allowed to, and should consider that 20 minute code as not existing. (Because on day 1 of her week, she could have written it properly.) That does not make it technical debt of 1 day. It means it didn't actually exist. Maybe this is really a variation of the sunk cost fallacy or something similar, where if something seems to exist in some form, then people can't get their minds around the fact htat only 20 minutes of it actually exists and the rest simply doesn't and needs to be written if they want it to. EDIT: all these downvoters are wrong. You say "now you have both wasted time" but the 20 minutes wasn't debt. It was the cost of the call option. For example in the other poster's example where a salesperson sold some code that didn't exist, his non-programming version of it wasn't debt toward the final thing: it was the cost he paid for the call option of being able to sell the whole thing. Hopefully he sold the option under cost :) his payment on the option has nothing to do with it.
  - samstokes 12y ago
    Maybe she shouldn't be allowed to, and should consider that 20 minute code as not existing. (Because on day 1 of her week, she could have written it properly.) Completely agree with this, and I wish it was said more often. Prototypes are a valuable tool for testing hypotheses, but you have to discard them when testing is no longer all you're doing. That means the key to responsible use of prototypes is to make sure you remain able to discard them! This is why shipping the prototype is so dangerous - because now you're locked into either maintaining the prototype, or a rewrite followed by a tricky, risky live migration.
hw 12y ago
While I agree with you that the notion of 'technical debt' is being overused, I don't think the article is talking about hidden costs as technical debt, but is instead about how product and code complexity incurs hidden costs, some of which but not all can be construed as technical debt. Code complexity is a good example. A part of a codebase can be complex (sometimes the problem that is being solved necessitates a complex algorithm / codebase) but yet well written. That does not incur technical debt, but there is a hidden cost to maintain it given it's complex. On the other had, a complex code base, that was done hackily in a few hours just to get to the solution without any thought for maintainability or has no test coverage, is technical debt, because the person 'borrowed' time amongst other things with the hacked up codebase, which in the future he/she must pay down by refactoring / writing tests.
- aswanson 12y ago
  On the other had, a complex code base, that was done hackily in a few hours just to get to the solution without any thought for maintainability or has no test coverage, is technical debt, because the person 'borrowed' time amongst other things with the hacked up codebase... Yup, usually because some sales/marketing/managing idiot had to have something look nice at a show and then wonder why an engineer is wasting time stabilizing the code base before he can give it to a customer. "It worked at the show...WTF?"
- chriswarbo 12y ago
  > A part of a codebase can be complex (sometimes the problem that is being solved necessitates a complex algorithm / codebase) but yet well written. I tend to use the following terminology to distinguish necessary an unnecessary complexity: | Easy Problem | Hard Problem Easy Solution | Simple | Simplistic Hard Solution | Complicated | Complex
  - notduncansmith 12y ago
    Is a hard problem with an easy solution really a hard problem? A more accurate chart might look like this: | Simple Problem | Complex Problem Simple Solution | Easy | Elegant Complex Solution | Stupid | Necessary
samstokes 12y ago
I think you're arguing against people using the phrase "technical debt" as a criticism, but those people are missing the point. Technical debt isn't a perfect metaphor, but there's an aspect of it I think you're neglecting - the interest payments. The point about debt isn't that you'll have to pay it back [1], but that you pay an ongoing cost until you do. In the technical debt case, the ongoing cost is opportunity cost - the initial quick hack may make it harder to evolve the code, or you may have to spend time fixing bugs instead of adding features. As with financial debt, if that ongoing cost doesn't matter - because the payoff outweighs the compounded ongoing cost, or because you can offset the ongoing cost with other sources of cash flow / bandwidth - then taking the debt was the right call. If you abandon the project (declare bankruptcy) then you never have to pay off the debt :) If you "make it big", though, someone eventually will want to pay it off. Either you make it big by becoming a successful business, in which case your time horizon extends, and at some point the interest payments compound enough that you don't want to pay them any more. Or you sell to someone else, in which case they have the same problem, and (if they're smart) they should have paid you less because you sold them a liability along with an asset. [1] Most financial debt has a maturity date, so eventually you do have to pay it back, although not if your lender is willing to indefinitely roll over. Technical debt generally has no maturity date, so you really don't have to ever pay it back!
- logicallee 12y ago
  nothing personal, but turns out you happen to be totally wrong. :) we can just look through examples until you realize this. It is like saying if I sell you a luxury mansion in the Hamptons that comes with nice hedges, for $1, I've really sold you an $800 interest payment, since you'll want to keep paying a gardener to trim the hedges, since if you don't it will hurt the price of your property long-term. you want to retain the value. Do you see how considering the $1 as coming with an $800 interest payment (until you replace the hedges with gates at even greater cost) is a totally wrong way to consder what has just happened? The fact that someone (you) will want to pay something doesn't make it anything close to debt. It's an unhedged (heh) call option.
  - samstokes 12y ago

aba_sababa 12y ago

And then your teammate then takes a week to build an API that's only compatible with your hacked out code you wrote in twenty minutes. Now you've wasted both your time and her time when both need to be re-written.

logicallee 12y ago
Yes, consider what has happened here carefully. Maybe she shouldn't be allowed to, and should consider that 20 minute code as not existing. (Because on day 1 of her week, she could have written it properly.) That does not make it technical debt of 1 day. It means it didn't actually exist. Maybe this is really a variation of the sunk cost fallacy or something similar, where if something seems to exist in some form, then people can't get their minds around the fact htat only 20 minutes of it actually exists and the rest simply doesn't and needs to be written if they want it to. EDIT: all these downvoters are wrong. You say "now you have both wasted time" but the 20 minutes wasn't debt. It was the cost of the call option. For example in the other poster's example where a salesperson sold some code that didn't exist, his non-programming version of it wasn't debt toward the final thing: it was the cost he paid for the call option of being able to sell the whole thing. Hopefully he sold the option under cost :) his payment on the option has nothing to do with it.
- samstokes 12y ago
  Maybe she shouldn't be allowed to, and should consider that 20 minute code as not existing. (Because on day 1 of her week, she could have written it properly.) Completely agree with this, and I wish it was said more often. Prototypes are a valuable tool for testing hypotheses, but you have to discard them when testing is no longer all you're doing. That means the key to responsible use of prototypes is to make sure you remain able to discard them! This is why shipping the prototype is so dangerous - because now you're locked into either maintaining the prototype, or a rewrite followed by a tricky, risky live migration.

hw 12y ago

While I agree with you that the notion of 'technical debt' is being overused, I don't think the article is talking about hidden costs as technical debt, but is instead about how product and code complexity incurs hidden costs, some of which but not all can be construed as technical debt. Code complexity is a good example. A part of a codebase can be complex (sometimes the problem that is being solved necessitates a complex algorithm / codebase) but yet well written. That does not incur technical debt, but there is a hidden cost to maintain it given it's complex. On the other had, a complex code base, that was done hackily in a few hours just to get to the solution without any thought for maintainability or has no test coverage, is technical debt, because the person 'borrowed' time amongst other things with the hacked up codebase, which in the future he/she must pay down by refactoring / writing tests.

aswanson 12y ago
On the other had, a complex code base, that was done hackily in a few hours just to get to the solution without any thought for maintainability or has no test coverage, is technical debt, because the person 'borrowed' time amongst other things with the hacked up codebase... Yup, usually because some sales/marketing/managing idiot had to have something look nice at a show and then wonder why an engineer is wasting time stabilizing the code base before he can give it to a customer. "It worked at the show...WTF?"
chriswarbo 12y ago
> A part of a codebase can be complex (sometimes the problem that is being solved necessitates a complex algorithm / codebase) but yet well written. I tend to use the following terminology to distinguish necessary an unnecessary complexity: | Easy Problem | Hard Problem Easy Solution | Simple | Simplistic Hard Solution | Complicated | Complex
- notduncansmith 12y ago
  Is a hard problem with an easy solution really a hard problem? A more accurate chart might look like this: | Simple Problem | Complex Problem Simple Solution | Easy | Elegant Complex Solution | Stupid | Necessary

samstokes 12y ago

I think you're arguing against people using the phrase "technical debt" as a criticism, but those people are missing the point. Technical debt isn't a perfect metaphor, but there's an aspect of it I think you're neglecting - the interest payments. The point about debt isn't that you'll have to pay it back [1], but that you pay an ongoing cost until you do. In the technical debt case, the ongoing cost is opportunity cost - the initial quick hack may make it harder to evolve the code, or you may have to spend time fixing bugs instead of adding features. As with financial debt, if that ongoing cost doesn't matter - because the payoff outweighs the compounded ongoing cost, or because you can offset the ongoing cost with other sources of cash flow / bandwidth - then taking the debt was the right call. If you abandon the project (declare bankruptcy) then you never have to pay off the debt :) If you "make it big", though, someone eventually will want to pay it off. Either you make it big by becoming a successful business, in which case your time horizon extends, and at some point the interest payments compound enough that you don't want to pay them any more. Or you sell to someone else, in which case they have the same problem, and (if they're smart) they should have paid you less because you sold them a liability along with an asset. [1] Most financial debt has a maturity date, so eventually you do have to pay it back, although not if your lender is willing to indefinitely roll over. Technical debt generally has no maturity date, so you really don't have to ever pay it back!

logicallee 12y ago
nothing personal, but turns out you happen to be totally wrong. :) we can just look through examples until you realize this. It is like saying if I sell you a luxury mansion in the Hamptons that comes with nice hedges, for $1, I've really sold you an $800 interest payment, since you'll want to keep paying a gardener to trim the hedges, since if you don't it will hurt the price of your property long-term. you want to retain the value. Do you see how considering the $1 as coming with an $800 interest payment (until you replace the hedges with gates at even greater cost) is a totally wrong way to consder what has just happened? The fact that someone (you) will want to pay something doesn't make it anything close to debt. It's an unhedged (heh) call option.
- samstokes 12y ago