Live data from Hacker News

The great software quality collapse or, how we normalized catastrophe

techtrenches.substack.com

241–250 of 260 posts

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

#241

Earlier quoted context omitted.

I don't think software has gotten worse, quite the opposite, but Java and OOP were mistakes.

Every time someone says this I ask them “what is your solution for maintainable software architecture?” And they say “what is software architecture? I just write code”

Non-OOP is pretty mainstream practice already, and it's maintainable. They even redid React. Java conceded a bit with newer features like lambdas.

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

#242

Earlier quoted context omitted.

Every time someone says this I ask them “what is your solution for maintainable software architecture?” And they say “what is software architecture? I just write code”

I’ll bite: use objects sparingly, and mainly to namespace functions that operate on data. Use inheritance even more sparingly, because it’s a nightmare to work with a poorly conceived inheritance hierarchy, and they’re so easy to get wrong. Pure interfaces are an exception, in languages where you need them. Write mostly functions that transform data. Push IO to the edge where it’s easy to swap out. Most importantly,…

Yeah Go and Rust made the right choice of not supporting inheritance at all.

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

#243

Earlier quoted context omitted.

> If all the examples you can conjure are decades old They're not ALL the examples I can conjure up. MCAS would probably be an example of a modern software bug that killed a bunch of people. How about the 1991 failure of the Patriot missile to defend against a SCUD missile due to a software bug not accounting for clock drift, causing 28 lives lost? Or the 2009 loss of Air France 447 where the software displayed all s…

In aviation, accidents never happen because of just a single factor. MCAS was mainly an issue in lack of adequate pilot training for this feature, AF447 was complete incompetence from the pilots. (the captain when he returned to the cockpit, quickly realized what was happening, but it was too late)

There's almost never a death where there is a single factor, regardless of aviation or not. You can always decompose systems into various layers of abstractions and relationships. But software bugs are definitely a contributing cause.

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

#244

Earlier quoted context omitted.

> You're missing the point. In the past bad writing was just bad writing, and it was typically easy to detect. If AI generated text were well written, would it matter to you? Is it bad to use Grammarly? I don't see anything inherently wrong with using AI tools to write, as long as writers take the responsibility to ensure the final result is good. Fighting against use of LLMs seems like a fool's errand at this point.…

> If AI generated text were well written, would it matter to you? Yes, of course. 1) I don't want to waste my time with slop pumped out with a mindless process by someone who doesn't give a shit. That includes turning half an idea into a full essay of bullshit. 2) You have to distinguish between "good writing" and (lets call it) "smooth text construction." One of the big problems with LLMs is they can be used to gene…

I understand your argument, but the distinctions you are making seem really hard to uphold. Adapting to LLMs means we'll adopt new standards for quality or more likely re-emphasize old ones like assigning trust to specific authorities.

If you read something from Simon Willison, it's generally worth reading. [0] (Actually pretty great a lot of the time.) Everything else is the literary equivalent of spam calls. Maybe it's time to stop answering the phone?

[0] https://simonwillison.net/

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

#245
post #228

Earlier quoted context omitted.

No, I never said they deserve it. But if you have a business, and don't have continuity and recovery plans for software disasters, that's like not having fire insurance on your facility. Fire insurance (and backups/disaster recovery plans) doesn't mean there won't be disruption, but it makes the disaster survivable, whereas without it your business is probably ended. And losing a database or a major part of one is as…

> No, I never said they deserve it. That's the gist of your argument. They're not a "serious business", therefore it's their fault. Let's not mince words. > It happens, I've helped recover from it, and it doesn't take an AI running amok to do it. Again, losing a database is not the issue. I don't know why you fixated on that. The issue is that most modern software is buggy and risky to use in ways that a typical busi…

Bugs are another reason you have backups. There are any number of ways you can lose data. Hardware can fail. Electrical surges can fry your computer.

If your business depends on that data, then you take steps to protect it. Or not, at your peril.

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

#246
post #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 b…

The problem with constant updates is that usually developers will make it so that the app stops working unless you update.

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

#247

Earlier quoted context omitted.

> If AI generated text were well written, would it matter to you? Yes, of course. 1) I don't want to waste my time with slop pumped out with a mindless process by someone who doesn't give a shit. That includes turning half an idea into a full essay of bullshit. 2) You have to distinguish between "good writing" and (lets call it) "smooth text construction." One of the big problems with LLMs is they can be used to gene…

I understand your argument, but the distinctions you are making seem really hard to uphold. Adapting to LLMs means we'll adopt new standards for quality or more likely re-emphasize old ones like assigning trust to specific authorities. If you read something from Simon Willison, it's generally worth reading. [0] (Actually pretty great a lot of the time.) Everything else is the literary equivalent of spam calls. Maybe…

> Adapting to LLMs means we'll adopt new standards for quality or more likely re-emphasize old ones like assigning trust to specific authorities.

I think we're in violent agreement, I just have a less sanguine attitude towards it. LLMs will "undermine processes and technologies that once created a huge amount of value" (to quote myself above). We'll adapt to that, as in life goes on, but major things will be lost.

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

#248

Speaking from the IT side of things: this is not new to AI, but the author hits the nail on the head that general incompetence along with a dozen layers of abstraction has made quality a non-concern for developers the world over. People and companies both broadly just don’t care to build good products when cheap slop will sell at higher prices long enough for their RSUs to vest and the share price to rise. I am sick…

This! In my experience it started well before 2018 that we left QA and ISO 25010 behind and I had to specialise in performance optimising software and hardware. By 2018 we were well downhill in terms of sheer number of bugs and perpetual emergency interventions. The amount of money we made by teaching customers how to performance- and resource-optimise their code and databases allowed me to retire in 2019. Which yeah. Since then, the situation even for me as a private user has gone further downhill: the endless bloat Microsoft alone distributes with every monthly update; the horrible amount of bugs in new games - even by big names like Blizzrd, EA - I'm confident in saying that they ship beta versions now - is, for me, an indicator that a problem like Y2K today would have extraordinary consequences. So yes, I understand being tired of it all, particularly in a work environment.

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

#249

Earlier quoted context omitted.

> It’s becoming exhausting to avoid all of these commonly used phrases! That's not the only price society pays. It makes sense for us to develop the heuristics to detect AI, but the implication of doing so has its own cost. It started out as people avoiding the use of em-dash in order to avoid being mistaken for being AI, for example. Now in the case of OP's observation, it will pressure real humans to not use the fo…

As long as we can swear more, we’ll be ok. X1 is bullshit to argue about, it’s about X2. Since the models are so censored and “proper” in their grammar, you can pretty easily stand out

I've found swearing to be a pretty decent heuristic for whether I'm talking to an actual person or not. Either it'll remain a decent heuristic or we'll get some Malcolm Tucker-esque LLMs out of it!

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

#250
post #208

Earlier quoted context omitted.

I blame software updates. That's when software went from generally working on release to not at all. Agile management methods set up a non-existent release method called "waterfall" as a straw man, where software isn't released until it works, practically eliminating technical debt. I'm hoping someone fleshes it out into a real management method. I'm not convinced this wasn't the plan in the first place, considering…

Ha. I was tasked to teach (classic) Project Management without being super-familiar. Then I had to get familiar with the new stuff; waterfall, agile whatever. They literally are all nothing but hacks that violate the basic points of actual project management. (e.g. Projects have a clear end)

From a PM point of view waterfall and agile can both have clear end dates. The main difference is in how they approach scope and quality to meet that deadline.
Post reply on HN