from Hacker News

Ask HN: Can bad code kill a product?

by krisgenre on 8/18/23, 3:05 PM with 6 comments

Software engineers often complain about bad code and architectures. But are there any real-world examples of products that started out successful but eventually crumbled due to technical debt?

I'm working on a 15-year-old SaaS service that has tons of poor code. We're making millions in profits, but we face scaling issues every day. We're able to keep things running by duct taping here and there but I'm wondering how long this can go on.

  • by PaulHoule on 8/18/23, 3:15 PM

    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.

  • by okl on 8/18/23, 6:17 PM

    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)

  • by anthony_franco on 8/18/23, 6:34 PM

    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.

  • by gardenhedge on 8/20/23, 8:33 AM

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

  • by aprdm on 8/19/23, 4:58 AM

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