3 ms·

It seems everybody here is suggesting that they have worked on products that were killed by technical debt. I'm going to take a different stance and suggest it

It seems everybody here is suggesting that they have worked on products that were killed by technical debt. I'm going to take a different stance and suggest it is very difficult for a product to be killed by technical debt. I'm working on a product now which has huge technical debt requiring a full re-write, but we have customers who love the product, so we just keep the old version going while building the new version. Let's assume we are talking about a single product company here, to make the discussion simpler and not get bogged down by larger corporate issues and it lets us focus on the case where the product is what is paying the bills (assuming we're talking commercial products here). Let's look at a few examples. The product has some customers, but it is difficult to add new customers due to some technical debt issue and the lifetime customer value for your target market does not cover the cost of re-developing your product and continuing operations. Ok, you're probably dead. You've got some customers, and you can't sell more, but the lifetime customer value is greater than the cost of re-engineering the system. You've got some bad times ahead, but there is a path. So technical debt doesn't kill you. You've got technical debt, and you don't have many users, you want to add features but can't because of technical debt. Did technical debt kill the product? Or was it killed by a lack of market? You don't know that the new features would have saved it, all you know is that what existed did not make enough to keep you going, so that can't really be blamed on the technical debt. Technical debt can be costly, but rarely fatal. It's great not to have it, it can make it difficult to keep good people (I lost 2 amazing devs partly because they hated the old code-base we inherited, but they also had amazing opportunities).

zzzcpan 10y ago
> You don't know that the new features would have saved it, Or could have killed it even faster. Imagine that at the beginning you decided not to accumulate "technical debt". Instead you got some product that developers believed had no "technical debt" and because of that it was late to the market. Money were running out and once customers started using it you had to be really lucky for new features to make enough impact to stay alive. Because customers don't necessary care that much about features that are easy to add, but maybe want some features that are hard to add and nobody anticipated that. Either way I cannot find a reason for "technical debt" to kill a product. I put "technical debt" in quotes, because even the underlying idea of the concept doesn't make sense and relies on a belief of knowing how to do it "the right way", which I don't think can be a good way to write software. It's better to substitute it with more complex concepts of flexibility and simplicity and corresponding trade offs.
- pedalpete 10y ago
  I think this point is very under appreciated, thanks for pointing it out. Along with the 'feature' that could kill things faster is general bloat when people keep building without knowing what the customer wants. You have to try something, but product testing should be done in such a modular way that most things can be removed if it turns out to be the wrong direction. Of course, you need a base data structure, but features should conform to that rather than constantly extend. One example I'm seeing with a start-up I currently know is that they are building SDKs for multiple languages. Most of the code is auto-generated, but just the time in examples, documentation and packaging is killing them while they don't have customers for most of the languages they're publishing. This isn't just 'code' debt, there is overhead in documentation and management of code.

zzzcpan 10y ago

> You don't know that the new features would have saved it, Or could have killed it even faster. Imagine that at the beginning you decided not to accumulate "technical debt". Instead you got some product that developers believed had no "technical debt" and because of that it was late to the market. Money were running out and once customers started using it you had to be really lucky for new features to make enough impact to stay alive. Because customers don't necessary care that much about features that are easy to add, but maybe want some features that are hard to add and nobody anticipated that. Either way I cannot find a reason for "technical debt" to kill a product. I put "technical debt" in quotes, because even the underlying idea of the concept doesn't make sense and relies on a belief of knowing how to do it "the right way", which I don't think can be a good way to write software. It's better to substitute it with more complex concepts of flexibility and simplicity and corresponding trade offs.

pedalpete 10y ago
I think this point is very under appreciated, thanks for pointing it out. Along with the 'feature' that could kill things faster is general bloat when people keep building without knowing what the customer wants. You have to try something, but product testing should be done in such a modular way that most things can be removed if it turns out to be the wrong direction. Of course, you need a base data structure, but features should conform to that rather than constantly extend. One example I'm seeing with a start-up I currently know is that they are building SDKs for multiple languages. Most of the code is auto-generated, but just the time in examples, documentation and packaging is killing them while they don't have customers for most of the languages they're publishing. This isn't just 'code' debt, there is overhead in documentation and management of code.