4 ms·

How about: All Of Them Every failed product/project I've worked on in my professional career, which had full intent to ship from the start, was killed by techn

by pslam 10y ago

How about: All Of Them Every failed product/project I've worked on in my professional career, which had full intent to ship from the start, was killed by technical debt. It's usually indirect, but it's always the root cause. It takes many forms: * Too buggy to ship, due to a creaky old code base being over-stretched to a product with too high reliability/experience expectations. * Product form factor, efficiency, user experience not good enough to sell well, due to spaghetti code base which couldn't be whittled down to removable pieces. Result: large runtime, more expensive, less efficient hardware. * Existing old codebase deemed too bad to ship a product, requiring a rewrite-from-scratch, but timescale too long to make any sense -> product killed. It's difficult to elaborate more while maintaining some discretion about exact companies and projects. The general point is: technical debt isn't just some fuzzy intangible issue — it indirectly creates enormous costs in people and time, can affect the physical form products take on, and impact the user experience. Products always get started without taking this debt into account, but when it's finally realized, it can change basic features, and then it kills them. Products are designed with faulty assumptions about what existing resources can be applied to them.

jkchu 10y ago
Interesting that you talk about project that never shipped, When I read OP's question I was thinking about already-shipped products that became too hard to run and maintain. I am curious how long your products/projects were in development for before falling to tech debt? Were these net-new projects?
- pslam 10y ago
  > When I read OP's question I was thinking about already-shipped products that became too hard to run and maintain. I've been mostly in consumer electronics related companies, where a product which ships and then becomes too hard to maintain usually doesn't "fail". It just gets phased out. In a way, this is another way technical debt has an indirect, but large impact on products: obsolescence becomes a necessity. Not so much planned — which implies malice — as simply realizing it's not possible to maintain indefinitely. > I am curious how long your products/projects were in development for before falling to tech debt? Were these net-new projects? Usually very quickly, or after far too long. The better projects know ahead of time that there are Dragons lurking in the code base. But that's effectively saying there are projects which never even got past brainstorming because we knew the technical debt was too high. On the other hand, there are projects where it only becomes apparent how much debt there is after a lot has already been invested. It's like you'd expect, e.g "There's a performance problem because of a basic primitive this library uses everywhere. And that was originally a workaround for a compiler performance bug. We could fix the compiler bug, but it turns out other libraries relied on it..." and so on. Extra time-to-market makes a product make less and less sense — fashions change, hardware improves, new tech arrives — and so it gets killed. Or worse, shipped.
bbcbasic 10y ago
Ironically you avoid technical debt by slowly killing and rebirthing parts of your product. The class that is no longer appropriate for new requirements gets canned for a better abstraction etc. In aggregate, over time, you may kill the product to avoid technical debt!

by pslam 10y ago

jkchu 10y ago

Interesting that you talk about project that never shipped, When I read OP's question I was thinking about already-shipped products that became too hard to run and maintain. I am curious how long your products/projects were in development for before falling to tech debt? Were these net-new projects?

pslam 10y ago
> When I read OP's question I was thinking about already-shipped products that became too hard to run and maintain. I've been mostly in consumer electronics related companies, where a product which ships and then becomes too hard to maintain usually doesn't "fail". It just gets phased out. In a way, this is another way technical debt has an indirect, but large impact on products: obsolescence becomes a necessity. Not so much planned — which implies malice — as simply realizing it's not possible to maintain indefinitely. > I am curious how long your products/projects were in development for before falling to tech debt? Were these net-new projects? Usually very quickly, or after far too long. The better projects know ahead of time that there are Dragons lurking in the code base. But that's effectively saying there are projects which never even got past brainstorming because we knew the technical debt was too high. On the other hand, there are projects where it only becomes apparent how much debt there is after a lot has already been invested. It's like you'd expect, e.g "There's a performance problem because of a basic primitive this library uses everywhere. And that was originally a workaround for a compiler performance bug. We could fix the compiler bug, but it turns out other libraries relied on it..." and so on. Extra time-to-market makes a product make less and less sense — fashions change, hardware improves, new tech arrives — and so it gets killed. Or worse, shipped.

bbcbasic 10y ago

Ironically you avoid technical debt by slowly killing and rebirthing parts of your product. The class that is no longer appropriate for new requirements gets canned for a better abstraction etc. In aggregate, over time, you may kill the product to avoid technical debt!