Live data from Hacker News

The great software quality collapse or, how we normalized catastrophe

techtrenches.substack.com

121–130 of 260 posts

Re: The great software quality collapse or, how we normalized catastrophe

#121

Earlier quoted context omitted.

And they somewhat have a point. What's the point of code quality, if it delays your startup 6 months, and the startup goes under? What's the point of code quality, if it will be replaced with the newest design or architecture change in 6 months? What's the point of planning for 5 years if a pandemic or supply chain shock could muck it up? What's the point of enforcing beautiful JQuery code... in 2012? The problem isn…

What in the bad rhetoric is this? The trades did and still do have standards. Hell there was a whole TikTok cycle where people learned there is a right and wrong way to lay tile/grout. One way looks fine until it breaks, the other lasts lifetimes. It’s the exact same trend as in software: shitty bad big home builders hire crap trades people to build cheap slop houses for suckers that requires extensive ongoing mainte…

> The trades did and still do have standards.

Yes, they do; after regulation, and after the experimentation phase was forcibly ended. You can identify 'right and wrong' tile work, precisely because those standards were codified. This only reinforces my point: we're pre-standardization, they're post-standardization, and most pre-standardization ideas never work out anyway.

Re: The great software quality collapse or, how we normalized catastrophe

#123
post #73

Earlier quoted context omitted.

Is this measureable? Like code readability scores on the GitHub corpus over time?

Maybe. Personally I've observed an increase of major system and security failures in the past 5 years, especially failures that impact very large tech companies. You could measure these public failures and see if frequency or impact has increased.

The number of security failures now is nothing close to the golden age of malware in the 90s/early 2000s.

The #1 security exploit today is tricking the user into letting you in, because attacking the software is too hard.

Re: The great software quality collapse or, how we normalized catastrophe

#124
post #28

Unrelated but my current AI text flag is the use of "It's not X. It's Y." It's become so repetitive recently. Examples from this post alone: 1. "This isn't about AI. The quality crisis started years before ChatGPT existed." 2. "The degradation isn't gradual—it's exponential." 3. "These aren't feature requirements. They're memory leaks that nobody bothered to fix." 4. "This wasn't sophisticated. This was Computer Scie…

Yeah I can see this can be an irritating rhetorical device. It implies that the reader already has a certain judgement or explanation, and makes a straw man in order to turn around and then argue against it, throwing nuance out the window.

It's irritating on purpose, for engagement.

Re: The great software quality collapse or, how we normalized catastrophe

#125

Try Windows 98 and contemporary apps and you'll be surprised how janky the experience was. User-facing software wasn't any less buggy 20 or 30 years ago. The overall non-cherrypicked quality and especially security were actually a lot worse across the board, and stuff that won't fly today such as segfaults/crashes and lost data was pretty normal. There was a point in time (several, actually) when installing Windows X…

saying "windows 98 was bad too" is just an example that Microsoft has always had poor code quality. Back in the day Linux, for all its flaws, was generaly a lot more stable on the same hardware.

microsoft has a lot to answer for after 50 years of normalizing poor quality software

Re: The great software quality collapse or, how we normalized catastrophe

#127

I don't want to sound too dismissive, but all these arguments have been brought up time and again. The move from assembler to high level languages. The introduction of OOP. Component architecture / COM / CORBA / etc. The development of the web browser. The introduction of Java. 2018 isn't "the start of the decline", it's just another data point on a line that leads from, y'know, Elite 8-bit on a single tape in a few…

We have always had, and always will have, the quality of software that people are willing to pay for.

Re: The great software quality collapse or, how we normalized catastrophe

#128

Just false nostalgia memory. 20 years ago things werent any better. Software didn't consume gigabytes of ram because there was no gigabytes of ram to consume.

Nah, I don't think so -- it really was a big deal to have a bug back then, and software quality used to be a lot higher. We could go back and run some VMs to try to objectively quantify this (and it would be interesting to do so), but I'm personally confident my memory isn't being tinted by nostalgia.

The main reason is the ability to do constant updates now -- it changes the competitive calculus. Ship fast and fix bugs constantly wins out vs. going slower and having fewer bugs (both in the market & w/in a company "who ships faster?").

When you were shipping software on physical media having a critical bug was a very big deal. Not so anymore.

Re: The great software quality collapse or, how we normalized catastrophe

#129
I remember getting into a debate with a professor, who firmly told me human programmers would soon be obsolete because all code would be generated by tools. I told him it wouldn't be very good code and he said, "Who cares? Hardware is cheap!"

This was 2002. At the time it was code generation from UML, not AI, but let's face facts: people have failed to give sufficient fucks about software quality for a long time now. We're just at a new low point in a very long, very steep drop; the only significance of this low point is that it means we're still falling.

Recently, I saw a video[0] about the game Sonic Racing CrossWorlds. The creator seemed impressed that Sega managed to put out a decently optimized Unreal Engine 5 game, that could hit 60fps without relying on generated-frame fuckery-duckery, and which provided a lot of content in less than 20 GiB. It used to be that optimization to obtain a decent frame rate and avoid bloat was table stakes for game dev. But it's 2025, and this is where we are now. Because video games are enterprise software, the tooling for gamedev itself is optimized around the path of "get the slop out quickly then fix later (maybe)".

[0] https://m.youtube.com/shorts/RRToQRmzCDI

Re: The great software quality collapse or, how we normalized catastrophe

#130
The article is spot-on. This should be a direct concern for anyone in the software industry, and given that software is eating the world, to society and governments at large.

The key phrase is this: "choose carefully".

Software developers have the responsibility to carefully choose their software stacks, the software they depend on, and how their own software is built. And the onus is on people using software to carefully choose software they trust, and software that doesn't restrict their freedoms or exploit their data.

Simplicity plays a big role in this choice. The less software we write and depend on, the lower the chances for it to do the wrong thing. We can't guarantee this, of course, given the insane complexity and layers of abstraction we must depend on, but making an effort is all that matters. Sometimes this choice requires trading convenience, time, effort, or money—but the sacrifice is very much worth it.

Post reply on HN