Ask HN: Can bad code kill a product?

Friendster was one of the first big social networks but the amount of users slowed it down. That made everyone move over to MySpace/Facebook.

If I remember right, Friendster had a feature that told you how you were connected to every other person (friend of a friend of a friend, etc.). And it was this feature that made the pages slow to load.

See

https://news.ycombinator.com/item?id=25618278

particularly Netscape was a good example now that I am reminded of it. Netscape was coded up by FORTRAN programmers and had a layout engine that was remarkably fast for the old HTML (stupid and smart in equal proportions.)

There was no way to retrofit it to support CSS and I think the W3C and Microsoft knew it.

Tech debt destroys programmers: there is a comment in that thread to the effect that programmers might get fired, but they also quit or go insane. I worked on a project that started when the source code repository for the previous version of the system was deleted by a developer who “cracked”. (Found that out long after I was deep in it!)

One factor is competition: Netscape had Microsoft following in its heels with a better product and the best distribution channel possible. If your firm is in a stagnant market then slow and painful development isn’t a danger to it. If a competitor comes along with something way better, you are in trouble.

A case that fascinates me is the lifecycle of communication apps, remember Paltalk or Tivejo (the fork of Paltalk I helped make for Brazil) or ICQ or AIM or MSN Messenger or CuSeeMe or GoToMeetimg or WebEx? Apps like this always seem to die and get replaced and I wonder what the underlying cause is, technical debt is one of the suspects.

I have worked on several but can't go into much detail. One was a big industrial machine with a control software with 7-8 digits lines of code written in assembly language, some FORTRAN, some Ada, distributed over several processors. Problem was that the manufacturer started in the 70s and never made any attempt to document, rewrite, reengineer the system. Another project with similar characteristics suffered because they were switching tools so fast that they didn't trust them and ended up hoarding all information in the code and never deleted anything.

Both projects swallowed millions, had subcontractors that went bankrupt and are still going because without those products the respective companies would go out of business.

If you want to make an argument against duct-taping, I'd try to focus on the immediate effects, argue cost/benefit, because in my experience the demise of a project/product can be long of painful (sunken cost fallacy)

It can help kill a product when a disruptor comes along and has something that performs better

Absolutely it can. But it's rarer than you think.