Ask HN: Have you ever worked on a product that was killed by technical debt?

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

That's why ASCII was designed with record and field separators. Unfortunately, it's not used (de facto) for delimited files.

Oh yeah, I've had a few projects killed by technical debt.

A lot of these are game mod related. Since hey, even the base game is a black box loaded with the technical dev of a team that could have been gone for decades. And the very tools and patches you're using on top of it were then also by people wanting theings done the 'quick' and 'easy' way over the 'right' way. Usually because said people constructed the tool in question for their project, and had designed it specifically for the environment they were working in rather than anyone else's. So you'll often see such a project completely fall apart because you don't understand all the code you used or how it interacts with the other stuff you used without understanding it.

But a few were actual work projects for clients. These fell apart because the following sequence of events occurred:

1. A coder was hired to work on the system and had a very different coding style to everyone else in the company. They thought they were being 'smart' but had overengineered the project by about a hundredfold.

2. They got sacked without telling anyone else how the project was constructed or why it was built that way. So developer B took over.

3. Developer B tried to 'rewrite' the system completely, but ended up merely creating a hodgepodge of his work and the other developer's work that ended up being rather unstable.

4. More features were requested from the client (which the system wasn't designed for), so three more developers each added them on independently. None of this work was commented, documented anywhere or stored in version control, so they bolted the features extras on, tested just that one part of the system and claimed it worked fine.

5. Project ran into large numbers of bugs, often ones which crashed the system or took down the database for a while. Multiple times a day, whatever developer was free would have to apply patches to whatever random thing stopped working in the last few hours.

6. Everyone ended up complaining that the system didn't work. Or that it should be rewritten. Or that it wasn't what the client 'wanted' at all despite the latter having changed their plans three times this week.

Either way, what should have been simple websites turned into giant unwieldy messes that no one developer understood the full design of. Which sat in endless limbo while developers ran around trying to patch up problems caused by no one having a coherent plan for the whole project.

"Relational" means "tabular". (A "relation" in relational theory is a table with a name, fields with names and types, and the data in the table.)

A "relationship" in an ER diagram maps to a "reference" in relational theory. This is part of the type safety/domain system of RDBMSs.

If these concepts are muddled, SQL will never quite make sense :)

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