3 ms·

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 thou

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

Espressosaurus 12y ago
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.

Espressosaurus 12y ago

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.