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

I did a Flex/AIR project a few years ago. At the time, it was a customer requirement. They had fired their previous provider, because their business model was to charge a subscription fee for the server-based product.

All their "media" was in flash format; so they made it a requirement, even though they could have saved themselves many tens of thousands of dollars in hardware costs by going to a mobile platform. (they did not have reliable access to networking in most of their deployments, and didn't want to bear the costs of rolling their own with cellular).

So I wrote the app in a "AIR isolated thick client" mode. There were many problems with garbage collection and application freezes, that could have been addressed had they funded migration to post-Adobe FLEX (Apache FLEX). But they ran out of funds for that.

Their platform was Win 7 laptops. The first hardware iteration was fine. The next year, when they started replacing the laptops, they hit a driver bug that caused the whole screen to freeze. With the next hardware iteration they were able to fix that, but they started having problems with AIR trying to download an update when they were not connected to a network (ie. deployed in the field). AIR behaved badly in this instance and refused to run.

When they moved to Windows 10, Adobe hadn't updated the AIR player yet, so they had another botched deployment.

It was in our contract to hand over the source code, so they tried to hire their own developer. I spent many hours very thoroughly documenting the code, and they had no hours budgeted for ongoing support. Judging by some of the desperate emails I was getting last year, before my Program Manager told them to fuck off, I think my documentation was not enough. Of course: the Dev Environment setup was Win 7, Eclipse 3.x with the Adobe plugin. I maintain a VM of the dev environment, but I doubt even I could follow my own directions to set it up anymore since the Adobe SDK of that version is so difficult to locate.

Had they listened to my original recommendation to write the entire application in Java, they would still be running fine.

That was my most recent experience with "death by technical debt".

Many years ago; a product died simply because a competitor bought our company, and tried to sell both products (because theirs was a "consumer market product", and ours was "enterprise market"). Over the next 18 months, they cut development to the enterprise product, and tried to tart-up the consumer product to meet the needs of our enterprise customers. I was a major account manager, so I watched one by one as our frustrated customers dumped everything our company sold, and went to the other competitor. So that product wasn't so much killed by technical debt as it was killed by moron MBA's.

In the end; all of those products are obsolete because nobody used dedicated backup tape library software anymore. It became a very small market because tape backup hardware never got commoditized, and prices just never came down from "insane". Even blank tapes were more expensive than a removable hard drive. Poor people just back up to the cloud, pay rent to someone else for their own data, and end up losing it.

I can probably think of about a dozen other examples from my long and miserable career in software.

Have a small hardware one....

About 1986 I was tasked with moving a small block (a few KB) of data very quickly from cabinet A to B, with the racks full of custom electronics - no PCs, all original stuff on a flight sim with 386 Intel processors all over the place. The racks had Multibus backplanes.

I suggested a 'TAXI' fast optical link (oooh - optical..too radical) or a pair of Intel 589 (Ethernet) cards for an off-the-shelf solution. Nope, too expensive. Engineering Management suggested a twisted pair ribbon cable between the two adjacent racks - um, OK..

Long story short - me and the senior design engineer decided to use the Intel 8257 DMA controller chip to grab the bus and blast the data between the RAM on two cards.

After a short period of fails, we found that the engineers who designed our 386 cards did not bi-directional buffer the DMA request line onto the backplane as they never expected any other card except the master CPU ones to initiate a DMA, so the CPU cards could not see the line being toggled from elsewhere.

Engineers would not accept a change request for 'reasons'

Intel 589 cards is it then!

All because someone chose to omit one tristate buffer.

I'm currently watching this happen to a product from the outside. The company I work for has an ERP system from the late 80s, written in COBOL for the HP 3000 series computers. At the time, it was probably an excellent system; however, over the years it's had modernizations tacked on with no regard to actually improving the core system. Some examples:

* In the early 2000s, they added support for Windows NT to the product. Unfortunately, they did this with an MPE compatibility layer that means the entire thing still thinks it's running on an HP 3000, so controlling it programatically means writing MPE job streams.

* It was originally written to store data in COBOL records. When they added support for SQL databases, they apparently just copy-pasted the schema verbatim from the COBOL copybook format. This means the database has no foreign keys, FLAGS columns all over the place (including tables where you have to JOIN ON SUBSTRING), and, most egregiously, a table with ITEMNO_001, ITEMNO_002, ITEMNO_003, PRICE_001, PRICE_002, PRICE_003 and so on, which has to be queried three times and UNIONed to get the data out.

* Printing packing lists requires not only a specific model of printer, but also an extra several-hundred-dollar chip to be installed in that printer. I'm told that this chip's sole function is to enable barcode printing.

I have no insight into what goes on inside the company that makes this thing, but it certainly looks to me like they have a severe case of technical debt. Any bug fixes generally take 4-6 weeks in the best case scenario, and frequently either don't fix the bug or introduce new ones instead. Their only customers are the ones that have been using the system for so long that they're stuck with the system, and can't switch--in fact, many of them are still running HP 3000 systems, which HP has been trying to end-of-life since at least 2006.

The end result of this is that the product is dying a slow, agonizing death of attrition. I think the only reason it still exists at all is because the company that makes it is stuck with support contracts that haven't expired yet.

I've learned over time that its always better to assume that who came before me were smarter than me and knew more than me (I'm rarely proved wrong).

It's a good question, because all software has "technical debt". Which means "technical debt" is not a real thing, but a concept invented out of a limited understanding of the problem. Instead, there is always a tension between a simple solution and a more flexible one and there is always a way to make things simpler or more flexible or even more complex and less flexible. For many problems the key to keep both simplicity and flexibility is to decouple everything as much as possible, i.e. share nothing, functions, not object with methods, scalar arguments, not complex structures, libraries, not frameworks, etc., but there is still a lot of room to do it better, like DSLs, metaprogramming.