[JohnFen]

> any software of any version that doesn't force auto-updates (e.g. not Chrome, not Skype) can also be "finished" if the particular user is satisfied with that old version.

I suppose. But the issue is that software releases used to have defined points where it was complete. With modern software, there is often no such point at all. Every "release" is just a snapshot of a continuous development stream, and is effectively a beta. There's a real difference between the two approaches. The latter is better for the devs, the former for the users.

[nradov]

A release is a release, regardless of the frequency. Quality control or lack thereof is an orthogonal issue.

Don't presume to know what users want. Early adopters often prefer to get new features as soon as possible even if that means working around defects and usability problems. Conversely, some enterprise software vendors still release on a very slow cadence because their customers don't want to do frequent acceptance testing or user retraining.

[michaelt]

> A release is a release, regardless of the frequency. Quality control or lack thereof is an orthogonal issue.

I'm not sure it's possible to separate quality from release schedule, when comparing to the old ways.

Back in the distant, ancient past, software had to reach a level of quality where it could be released by writing it to disks (or CDs, or engraving it into stone tablets) then sending it to stores, no patches possible.

Meaning there was Office 95 and it'd better be stable and reliable because the next release will be Office 97. Which will be a paid upgrade, so it'd better have enough new features that users are willing to pay.

This meant that there was no such thing as a bug or performance issue that could be dismissed with "we'll do it later" - it either got fixed before the release, or never. Modern software development techniques have eliminated any such deadlines.

And because in the past a company could be completely wiped out by a bad release, there were dedicated testing teams and suchlike, as by the time users started reporting bugs and complaining, it was too late. Good luck finding such a team these days!

[nradov]

Of course it's possible. I've done it. This requires a pretty high level of discipline and near 100% automated test coverage. Test scripts have to be written concurrently with product code, or at least prior to merging any code to the release branch.

I don't believe that software was actually higher quality in the distant past. That seems like selective memory. I've been in the industry long enough to have used a lot of products that shipped on physical media. There were many defects that we just lived with. Vendors frequently issued patches or dot releases on additional discs to fix defects.

[JohnFen]

I'm also an old-timer, from slightly before personal computers were a thing.

> There were many defects that we just lived with.

There were, indeed! What the most common defects look like is a bit different now than then, but I don't think software now is generally any less buggy than software then. The main difference is that now software is increasingly unreliable in the specific sense that it updates so frequently. Very frequent updates mean that things are constantly in flux. In my view, that alone is a decline in software quality.

[8n4vidtmkvmk]

Not just 100% unit test coverage but e2e integration tests too. My company really struggles with the latter because they take forever to run and they are flakey as heck. Most of our bugs are from badly mocked services.

[JohnFen]

> Don't presume to know what users want.

Fair. I should have said "me as a dev" and "me as a user".