Very good article. I feel that corporate executives as a class are causing this huge mess from a simple lack of understanding of software engineering. Throw more bodies at the problem has never worked in software engineering, in fact that's a surefire way to make things worse and slower.
Throwing more bodies + AI at the problem is even worse because the speed at which things get worse is much faster. If you have people that don't understand the implications of what they are doing, you're on the path of heading over a cliff some day.
AI is a useful tool, when put into the hands of someone that is competent. They can fire junior devs and refuse to hire them as much as they want, this strategy will come home to roost sooner rather than later.
If a C-level executive thinks that AI can replace their engineers, then I say do it now. Go all in and replace them all right now. Use only AI and a few VP-level AI whisperers and let the catastrophic failure that this will result in happen faster so we can get back to reality quicker.The great software quality collapse or, how we normalized catastrophe
251–260 of 260 posts
Re: The great software quality collapse or, how we normalized catastrophe
#252Earlier quoted context omitted.
Yeah, I bounced hard off the article at #5. My AI detector was slow warming up but kicked on at: "Today’s real chain: React → Electron → Chromium → Docker → Kubernetes → VM → managed DB → API gateways." Like, yes, those are all technologies, and I can imagine an app + service backend that might use all of them, but the "links" in the chain don't always make sense next to each other and I don't think a human would wri…
Every time I see a big chain of technologies as "bad", all I want to do is add more and see where the good/bad separation should be placed. So: API gateways -> Java servers -> JVM -> C/C++ -> Assembly -> machine code -> microprocessors -> integrated circuits -> refined silicon -> electronics -> refined metals -> cast metallurgy -> iron tools -> copper tools -> stone tools Anyway, my take is that everything after copp…
The fun part is where the chain diverges into separate branches for digital logic and the mechanics of constructing circuits.
Re: The great software quality collapse or, how we normalized catastrophe
#253Earlier 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…
I actually liked the em dash. But now I stopped using it. Probably will be good to use soon as AI gets trained to not use it.
Write it as three dashes instead---that's not what an LLM would do and anyone looking close enough will see the difference.
Re: The great software quality collapse or, how we normalized catastrophe
#254Earlier quoted context omitted.
I don't want to take the time writing up a cogent response to an article someone didn't bother taking the time to write. With this particular article, there were a couple of points I wanted to respond to, before I realized there was no human mind behind them. I've always liked the HN community because it facilitates an intelligent exchange of ideas. I've learned a lot trawling the comments on this site. I don't want…
I wonder how it's different from when a collegue sends you an llm PR.
You get paid
And it's the employers problem, if you don't react too much emotionally
Re: The great software quality collapse or, how we normalized catastrophe
#255While it doesn't really change the meaning of the article, it's pretty clear that it isn't the calculator app leaking memory, per se. Tahoe seems to have some system/API memory leaks that while they might get attributed to an app, can manifest against any app on the system. Lots of different apps have been hit by this. Personally I had an 80GB Messages app problem twice now. Software quality is a problem. Tooling sho…
That's definitely true. I've also seen online reports of Tahoe memory leaks in other apps like PowerPoint. It's unlikely that all these apps independently gained memory leaks at the same time by coincidence.
Re: The great software quality collapse or, how we normalized catastrophe
#256Lawrence J. Dickson anticipated this almost 2 decades ago in a research he did for DARPA in 2007[1]. Just look at the software development viscosity graph.
Re: The great software quality collapse or, how we normalized catastrophe
#257I recently experienced bad software at an airport that meant the wait in the passport queue was longer than the flight . I was in an airport recently waiting in the immigration queue for the automated passport gates - they had like 15 - of which 12 showed a red light and what looked like some C# error message on the screen ( comm problem talking to the camera ). As I waited in the very long queue, another of the gree…
I see. So you're saying you were also in Terminal 2 at Heathrow?
At it happens not this time.
Re: The great software quality collapse or, how we normalized catastrophe
#258Just 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.
> Just false nostalgia memory.
No, I don't think that's right, because:
> 20 years ago things werent any better.
I think you have the timeframe wrong.
20Y ago, no.
30Y ago, yes, somewhat. Win NT came out 32 years ago.
40Y ago, yes, very much.
No public internet, very slow point-to-point dialup comms for a tiny %age of users, and tiny simple software for very limited hardware meant better quality software.
I installed multiple Novell Netware servers on company networks, both Netware 2.15 and Netware 3.1. They never ever got updated, and ran flawlessly for years on end.
I installed dozens, hundreds, of machines with DOS 3.3 and they ran it until they were scrapped.
I put in multiuser systems based around SCO Xenix: Unix boxes, but with no networking, no GUI or X11, no comms, no compiler. They had uptimes in years: zero crashes.
Stuff was more reliable because it had to be because shipping an updated meant posting media to thousands of users and sending a human to install it. Nobody could afford it.
Software and hardware should be subject to the same laws as vehicles: if it fails in standard use, the maker is liable. So make it safe.
If that means it has to be 0.1% of the size and 0.1% of the functionality that it was 20Y ago, fine: so be it.
Because that's still huge and rich compared to the DOS stuff I started my career on. It is not some savage brutal unimaginable limitation, utterly unrealistic. It was the reality of end-20th century software around the time that the PC industry moved to 32-bit hardware at the end of the 1980s.
Re: The great software quality collapse or, how we normalized catastrophe
#259Just 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.
There's almost no product or piece of software that I use today that doesn't have at least 2 bugs that I run into on a daily basis. Every website, web app, mobile app, console app, etc, they all have clearly user-affecting bugs. And nearly every one of those makes it hard for me to diagnose or report the bugs. I spent at least 15 to 30 minutes every day working around bugs so I can live my life. We have a vastly diff…
> My Kubuntu 24.04 LTS box
Bad news... only the GNOME edition is a true LTS. All the flavours are not.
https://wiki.ubuntu.com/NobleNumbat/ReleaseNotes/Kubuntu:
Support lifespan
Kubuntu 24.04 will be supported for 3 years.
Re: The great software quality collapse or, how we normalized catastrophe
#260Just 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.
Exactly, and if you used machines 20-30 years ago you got used to all sorts of periodic terrible faults that could require rebooting the machine ("blue screens" or sad Mac, guru meditation, etc) or at least restarting the program. On top of that many things were simply hard to use for non-specialists, even after the introduction of the GUI. They were also riddled with security holes that mostly went unnoticed because…
> Exactly, and if you used machines 20-30 years ago
Bad news. We're older than we tend to remember.
Windows NT 3.1 shipped 32 years ago, the year after OS/2 2.0.
By 1994 NT 3.5 was out, and 30 years ago, NT 3.51 had been out for about 6 months.
I ran that and supported it in production and it was damned near bulletproof.