Hacker News Reader

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!

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.

If I can choose to pay full price for a luxury mansion or pay $1 for the same mansion, of course I should pay $1. That choice is not usually available, either in real estate or in software. More likely, I'm choosing between a studio for $200k and a 4 bed for $1m (adjust for regional house prices), or a cheap fixer-upper vs an expensive new-build.

The point of the debt analogy isn't to think about which parties are involved in the transaction; it's to think about the various kinds of costs involved in a decision, and the timescales over which they are paid.

From that point of view, if I can't afford the $800 hedge maintenance, then I shouldn't buy the mansion, even for $1. The strict analogy with debt breaks down a bit because I'm not paying you the $800, but it's still an ongoing cost I have to bear.

Edit to clarify, I'm still not saying debt is always bad. If I enjoy DIY and expect to have spare time, the cheap fixer-upper might be a great investment.

I think I see where you're going wrong here. We need to put some numbers to it.

Suppose you can make $20 if you spend $15 adding a feature. Obviously you should do it, right? You'll make $5. So you do.

Now the customer comes back and says the new feature doesn't work in some edge case and they won't pay the $20 unless you spend another $15 fixing it. At this point the original $15 is a sunk cost that you can't get back and you're presented with the original scenario again: Spend $15 to make $20. So now you've spent a total of $30 to make $20. This can repeat arbitrarily many times, putting you even further into the hole each time, until you recognize that hidden future costs mean that you're actually spending far more than $15 to make that $20.

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.

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

> 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

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

I think simplistic was meant to imply that it wasn't really a solution, just good enough for you.

That said, you can say the same case for your matrix: if there's a simple solution to a complex problem that actually solves it, is it really a complex problem?

Sure. "Complex" problems are problems with many facets/moving parts (I recommend watching the Rich Hickey talk "Simple Made Easy"). These problems can in some cases have simple (as in, few facets/moving parts) solutions, although those solutions may not be easy to implement.

You've repeated what I disagree with:

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

This is simply not true. It is exactly the same that a non-developer who managed to get an Excel spreadsheet on the web 'borrowed' time from a real developer if it takes off. How can you borrow time from a non-existing person? This just doesn't make sense. It's just an unhedged call option.

Let me give you an offer for your services. Suppose I ask you for a quote for a very simple database app where employees can punch in and punch out with a password, and it tracks their daily time between the two. Nothing exists including a mock-up. You give me a quote. Now suppose that some genius actually got excel online witohut password authentication, in twenty minutes, they can put in a URL and click a button for a timestamp. That's what we've been using three weeks.

Does the existence of this change your offer? Yes: it reduces it, because you can see exactly what we'r ehappy with. (Unless you're trying to take advantage of the shop for being non-technical and therefore increase your quote; in this example we can just hide the existence of it from you. But this is a pathological case.)

So how can you call it debt, when in fact all it is is a slight asset (we got three weeks of utility from it) that took a non programmer half an hour, and reduces the price you quote to write it properly by a certain amount?

It's not debt in any sense of the word. You don't 'have' to pay it, any more than you 'had' to pay it before the hack.

In the other poster's example. if the salesperson sold something under cost, he sold it under cost. But if he sold it over cost, then his demo didn't become technical debt of the actual cost, it was just worth 20 minutes by a non-programmer, exactly as though he hadn't done it. Except he did do it, becuase it helped him get the sale. It was an option.

A third example would be saying that any time I buy something crappy that I expect to break, I am creating technical debt. For example if I buy a crappy screwdriver that will break on my third project, I've really signed up for the debt of a real screwdriver. Huh. This is not a very sane way to think about it. (It's actually a good analogy for technical debt, if I only bought it to produce the first two projects, and wouldn't have started on the third if the first two didn't get traction and get sold, or maybe even result in an investment.)

Technical debt isn't a perfect analogy, but people understand it. It's like explaining that programming is just writing a recipe for the dumbest chef in the world--it's a good analogy, but doesn't capture the complexity or techniques of programming. Which is fine, because almost everyone is familiar with the idea of a recipe, and your explanation is for someone who probably thinks programming is this magic thing you do that makes Facebook pop up out of the ether!

An analogy that isn't understandable by its target audience is useless.

Given that most programmers' idea of finance is of some kind of magic that happens that makes money pop up out of the ether, you need to use the appropriate analogy.

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.

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.

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.