4 ms·

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

by 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
  - sbov 12y ago
    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?
    - notduncansmith 12y ago
      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.
logicallee 12y ago
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.)
- 12y ago

by hw 12y ago

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
- sbov 12y ago
  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?
  - notduncansmith 12y ago
    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.

logicallee 12y ago

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

12y ago