For what it's worth, Mozilla was nearly killed at least twice by code quality.

Once upon startup. The code inherited from Netscape was... let's say charitably difficult to maintain. Turning it into something that could actually be improved upon and tested took years without any release of the Mozilla Suite.

Once when Chrome emerged. Not because the code was particularly bad, but because its architecture didn't reflect more modern requirements in terms of responsiveness or security. See https://yoric.github.io/post/why-did-mozilla-remove-xul-addo... for a few more details.

> For what it's worth, Mozilla was nearly killed at least twice by code quality.

> That’s not to say that I now think that “High quality good! Low quality better!”. > As many commenters on Cupać’s post observed, while high quality isn’t necessary for success, it improves the chances of it.

_Nearly_ killed. But Mozilla is still kicking around. Maybe not doing the kind of internet-shaping work they once did (here's hoping they get back there), but they continue to exist.

I was in a successful company that nearly died in 2017, where our entire production system corrupted itself due to a sneaking scale bug we had ported the system into. The problem was, the system with data had been running migrated for 3 months with the bug in it, so it was no longer possible to revert to the earlier working design. We were down for a week where no clients could run, and we spent the next 12 months purely digging ourselves out of that hole, with all new development paused, and all hands on limping the ship along. I would say, that bug was very close to ending us. Luckily, we never disappointed in a similar way since.

What I’m hearing here is that even a software problem so bad it forced you to focus on nothing except trying to fix it, for a full year, wasn’t bad enough to make the company go under.

“My company didn’t go under” is pretty much the lowest bar you can shoot for.

This blog post is saying “Staying healthy doesn’t matter because neither I nor anyone I know died so far.”

This analogy is a bit tortured but it's honestly pretty good anecdata that something probably doesn't generally kill you if you've been around people doing it for 15 years and none of them have died yet. It can kill you, but that doesn't mean it generally does.

I'd love to come to the conclusion that it's wrong, but it's right. Most companies absolutely 100% can afford to ship bugs: the proof? They're doing it, they have been doing it, they will continue to do it. That doesn't mean that every company can, always, forever. A single really bad bug can tank a company. In the right conditions, simply being buggier to a superior competitor can tank a company. However, those are mostly just things developers fantasize about. The market is by and large not decided by how elegant and well-designed your software is, moreso in some verticals than others. In fact, this is basically true for almost anything that isn't explicitly developer oriented in the first place.

Just look at enterprise software. Jesus Christ.

People smoke from 15-20 years old but still don't die in their 30s. It doesn't mean it's not bad for your health. This is the same thing, it's bad for the health of the company. High dev turnover, poor working conditions, and productivity issues can all lead to a death from a thousand cuts, and even if the company doesn't actually go under, you can't say that a company didn't suffer because of it.

I'm going to be honest, this analogy is just not that good. You can draw some parallels to cancer and bad workplace culture, but it's a very skin-deep/awkward comparison in my opinion.

Well, what is your goal?

Sure, healthy and happy chickens are nice, but if you are into industrial farming and your goal is to make money, you will make their life as miserable as necessary to extract profit. You don't care if they are barely alive as long as the health standards are met.

It's not about you being happy as an individual, it's about the company making money. If your lawyers and sales are good enough to build a captive market of miserable customers, your company can still make a ton of money and be very successful.

From personal experience with early stage startups, it is quite a low bar. I've seen companies "acquired" for pennies on the dollar, after almost the entire staff is laid off. Somehow, this is considered a success even though you would've had an better outcome investing your time and money in almost anything else. Employees lost, investors lost. The founder often gets a cushy job they could've had anyway.

"and I've never met any dead people either"

I think that it is (a little bit) more subtle: the importance of quality OF A PRODUCT (projects delivery is another beast) is relative to:

- the customer: either B2B or B2C

- the market share: minimal (< 1%... including all startups) or dominant (> 30%)

- B2C is really dynamic and few bad versions/products can make the customers fly away (except when strong dominance - like Windows - or no equivalent product) and shutdown a company. Price can be a strong factor and cost of migration/switching is usually not considered

- B2B is more conservative: hard to enter the market (so small market shares will need a lot of time to take off... if there's no competitor) but once you're in, the cost of change for a company is usually high enough to tolerate more bad versions (and more if there's few competitors, and incompatibilities between products, and legal requirements to keep records, and a lot of "configuration", and requiring a strong training for a lot of people...). Companies as customer dont see the switch of software as a technical problem (replacing on editor by another one) but as a management problem (training, cost to switch, data availability, availability of people already trained, cost of multi-year/multi-instance licences...)

> It’s trivially easy to find counterexamples of companies failing because their software products were inferior to newcomers who delivered good results, fast development, and more stable experience.

Is it? What I've seen is the opposite.

Businesses can be terrible top to bottom, slow, inefficient, and painful for customers, and still keep going for years and years. It's more about income/funding than product.

> I think the author may have been swept up in big, slow companies that have so much money that they can afford to . . .

That's what I'm talking about. They are legion! They could be companies that serve a niche that no one else does or with prohibitive switching costs (training is expensive). They could also be companies that somehow got enough market share that "no one gets fired for buying IBM."

Also, you know what those "big, slow companies" have in common? They are successful businesses. Unlike most startups.

> It’s trivially easy to find counterexamples of companies failing because their software products were inferior to newcomers who delivered good results, fast development, and more stable experience. Startups fail all the time because their software isn’t good enough or isn’t delivered before the runway expires. The author is deliberately choosing to ignore this hard reality.

While I personally haven't seen a company going under due to bad code, one can also definitely make the argument that software that is buggy or doesn't scale will lead to lost profits, which could also eventually become a problem, or present risks to business continuity.

I still recall working on critical performance issues for a near-real-time auction system way past the end of my working day, because there was an auction scheduled the next day and a fix was needed. I also recall visiting a healthcare business which could not provide services, because a system of theirs kept crashing and there was a long queue of people just sitting around and being miserable.

Whether private or public sector, poor code has a bad impact on many different things.

However, once can also definitely make the distinction between keeping the lights on (KTLO) and everything else. If an auction system cannot do auctions for some needed amount of users, that's a KTLO issue. If an e-commerce system calculates prices/taxes/discounts wrong and this leads to direct monetary losses, that's possibly a KTLO issue. If users occasionally get errors or weird widget sizing in some CRUD app or blog site, nobody really cares that much, at least as far as existential threats go.

Outside of that, bugs and slow delivery can be an unfortunate reality, yet one that can mostly be coped with.

Agree.

For example, pg said that ViaWeb was successful because they had put care into their code, which allowed them to iterate quickly and integrate new features that customers requested. Whereas competitors were held back by their cumbersome code and slow cadence of releasing features.

pg would say that, though, because it was his company and it worked out for him.

But maybe he was actually wrong about quality being a differentiator, and his competitors could've shipped features with shitty code but had other problems.

Friendster is memorable example. It did not scale well, and fed up users flocked to MySpace and Facebook, which came later.

More generally it depends on how competitive the space the product operates in, whether quality is something the buyer values and is able to evaluate! Enterprises for example infamously don't appreciate quality as much consumers because the economic buyer does not use the product.

It should have been "going under due to bugs / low quality and slow delivery".