[scott_w]

I’m struggling with this post because it seems to imply that software quality has gotten worse over time. Bluntly put: I think this is nonsense.

I remember using Windows 9x, the running jokes about poor quality and security of all MS products. Adobe’s formats came from those early days and are roundly mocked. Hell, I’ve built replacements for 90s software and, I can assure you, what I replaced was not high quality or robust at all.

On this very site, we discussed Horizon: a project started in the 90s and 20000s that was so badly built that it led to hundreds of innocent sub-postmasters being imprisoned, bankrupted and a number committed suicide.

Is the author just romanticising the “good old days?”

[stakhanov]

I think there was a kind of "golden period" that goes in between.

In the 90s, the economics around software had already heated up to the point where there was an insatiable appetite for software engineering manpower, but the university system wasn't yet geared to churning out specialists in this field in such large numbers, so a lot of software engineers back then were people coming from other professions who picked it up autodidactically and were just not very good. At the same time programming languages and tooling weren't yet at a point where they were good at guiding people towards good software engineering practice, and this lead to a kind of software quality crisis.

But this situation changed fast. I would say from maybe roundabout 2003 to maybe roundabout 2013 there was a bit of a "golden period" where we had good reason to be optimistic about the future of software quality. The software quality crisis of the 90s was largely overcome through better education, better software engineering methodology, and better programming language ecosystems and toolchains. Back in those days we still had purpose-built tooling for doing things like desktop UIs. Windows Forms based in C# and Aqua-era MacOS GUI programming in ObjC were actually quite a good experience for both developers and users. We also had cross-platform ways of doing GUI programming like Swing on Java.

In the next ten years, i.e. the ten years leading up to now, things took a decided turn for the worse. If I were to speculate about the reasons, I would say it was related to the rise of mobile, and the continued rise in the importance of the web platform over the desktop platform, meaning that application development now had to straddle web, mobile, and desktop as three distinct development targets. This created a need for truly cross-platform application development, while Apple and Microsoft continued to make plays to fortify their monopoly power instead of giving the world what it needed. Swing/JavaFX lost its footing when enterprises decided that web was all they really needed.

So, to answer your intial question: Has software quality really gotten worse? I would say, yes, over the last 10-15 years definitely. If you compare now to the mid-90s, then maybe, maybe not.

[scott_w]

> Has software quality really gotten worse? I would say, yes, over the last 10-15 years definitely.

By what metric?

Taking all your above examples, I (and many others) could argue that the move to web brought new techniques that overall improved software for developers and users. That's not to say I'm right, or you are, but to point out that everything you put forward is purely subjective.

What has objectively gotten worse in the past 10 years?

[stakhanov]

> By what metric?

On the user's side: Just pick any set of well-established best practices such as Shneiderman's Eight Golden Rules or Nielsen & Molich's 10 Usability Heuristics, an then pick a typical 2024 electron app that has an equivalent from the 2003-2013 era and is written with a typical UI technology of the time (such as Windows Forms), and compare the two UIs with respect to those best practices. -- I'm pretty sure you will find usability blunders in today's software that you simply couldn't commit back then, even if you tried. -- Essential UI elements being hidden away (with no indication that such hiding is taking place) based on viewport size, leaving the user unable to perform their task is one thing that immediately comes to mind. Another example I happened to experience just yesterday: UI elements disappearing from underneath my mouse cursor when my mouse cursor starts to hover over them.

Also: Just look at the widget gallery in Windows Forms, providing intuitive metaphors for even quite subtle patterns of user interaction and check how many of those widgets you find implemented in modern web-based design languages and web component systems. ...usually you don't get much beyond input fields, buttons, and maybe tabbed-views if you're lucky. So today's software is relegated to using just those few things, where, 10 years ago, you had so many more widgets to pick and choose from to get it just right.

On the developer's side: Was JavaScript ever actually designed to do the things it's being used for today? Is dependency hell, especially in the web ecosystem, worse today than it was 10 years ago?

[scott_w]

> Just pick any set of well-established best practices such as Shneiderman's Eight Golden Rules

Excellent, we have something objective to look at. Now, where's the studies, reports, etc. that this has declined in the past decade? I'm not asking for a double-blind, peer reviewed study, just something a bit more concrete than "stop the world, I want to get off."

> Was JavaScript ever actually designed to do the things it's being used for today?

Was anything?

[stakhanov]

> > Just pick any set of [...]

> [...] Now, where's the studies, reports, etc. [...] "stop the world, I want to get off."

This argument is getting a bit tediuos. It started with you offering an opinion. I offered a counter-opinion, while clearly marking my opinion as such using language such as "I think ...", "I would say ...", "If I were to speculate ..."

I'm clearly not alone with my opinion (see original post), and you're trying to undermine your opponents' credibility by getting ad-hominem and pointing out that their position lacks the kind of research which you yourself did not provide either.

> > Was JavaScript ever actually designed to do the things it's being used for today?

> Was anything?

Hyperbole. Many things were designed to do the things they now do. Lua was designed as a language for embedding. SQL was designed as a language for querying databases.

[scott_w]

> I'm clearly not alone with my opinion (see original post),

I recall seeing the same thing being said in the 2000s on Slashdot, so "software is shit now" is an opinion that's not new.

> and you're trying to undermine your opponents' credibility by getting ad-hominem and pointing out that their position lacks the kind of research

All I'm saying is that this popular position of "software used to be so much better" has strong "kids today" vibes.

> which you yourself did not provide either.

I'm not the one saying an entire industry has forgotten how to do our jobs.

[nottorp]

> By what metric?

I've never seen a chat app taking gigabytes of RAM before Electron, for example.

I've extremely rarely seen applications going nuts, eating several CPU cores and draining my battery in 20 minutes before Electron, for example. Now it's a weekly occurence.

It's improved only for developers who only know web development. And we users pay for it in hardware costs, electricity costs etc.

[scott_w]

> I've never seen a chat app taking gigabytes of RAM before Electron, for example.

Is that a general software problem or a problem specific to Electron? Is that a permanent problem or a problem right now because of the technology and your attitude towards it?

I say this because I do recall seeing complaints about Java being bloated in the 2000s. I briefly used Swing in my university days and it was pretty awful compared to HTML at the time. In 2044, maybe I'm going to be shaking my fist at the new-fangled tech and telling everyone how nice Electron apps were in comparison.

[nottorp]

> complaints about Java being bloated in the 2000s.

It's bloated in the 2023s too. Last year I caught Android Studio (which I wasn't even using at the moment, just had it open from a quickie fix a few days ago) going over 4 Gb of ram. I had two projects open, under 20k lines of code total (ok, maybe I should count again).

But why bring Java in? We're talking about native applications vs applications that pull in a copy of Chrome and half of the npm registry. Java isn't native either.

[scott_w]

> But why bring Java in?

Why not?

> We're talking about native applications vs applications that pull in a copy of Chrome and half of the npm registry.

You might be but I'm not. I'm talking about the state of software in the 1990s, 2000s, 2010s and today and how a general "it's worse" isn't particularly useful (or probably even true).

[llanowarelves]

Well-written comment. I would love to read an extended version of this with examples, pictures, etc. as a blog post / youtube video.

[mixmastamyk]

The move to ubiquitous CI, unit testing, and version control (quality improvements) are orthogonal to dependency bloat.

Bloat does increase attack surface as mentioned.

There was reliable software in the old days as well. VAX/VMS, Windows NT 3.5x, my SGI workstation. Few wanted to pay for it. Today we have FLOSS.