[jasode]

>Let me introduce you to WordStar 4.0, a popular word processor from the early 80s. [...] I love how he puts it: It does everything I want a word processing program to do and it doesn't do anything else. [...] , remember that sometimes, the best software is the one that doesn’t change at all.

If we take your Wordstar 4.0 example literally, it's not a good example of the concept I think you're trying to convey. Wordstar did change for 7+ versions after 4.0: https://en.wikipedia.org/wiki/WordStar#Version_list

Wordstar didn't freeze at 4.0. Instead, what happened was George R. R. Martin's idiosyncratic usage of word processing froze at WS 4.0. That's a very different concept.

If we define "finished software" as determined by the end-user instead of the developer, then 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. E.g. In that mental framework, Adobe CS6 from 2012 and Windows 95 can also be "finished software" because the user doesn't need/want Adobe CC 2023 and Windows 11.

Maybe a better example of "finished software" from the perspective of developer would be a one-off game where the programmer never had intentions of making franchise sequels out of it.

[justin66]

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

That’s obviously not true. WordStar 4’s output is interoperable with newer software, it runs on today’s hardware with a little work, and a user won’t be under constant threat of getting hacked because they’re running an old version. It is safely “finished” in a lot of ways the other software Martin was using when he settled on WordStar is not.

[pjmlp]

Having written printer drivers for MS-DOS, I doubt Wordstar will work properly with modern printers.

[justin66]

I have a few thoughts on how I'd try to make it work, but it does look like WordStar 5, which came a year later, would be an easier one to try, with its Postscript support.

[pjmlp]

Maybe, except that it would require passing that Postscript file into another application, or getting a Laserprinter still able to plug into MS-DOS infrastructure or FreeDOS.

Anything requiring moving the Postscript file via other applications or operating systems, is working around the problem of WordStar not really working on modern infrastructure.

[justin66]

I think you’d probably use vDos (or something similar) today if you tried to do run old WordStar with modern hardware. I gather there are some features available that help with printing.

I actually used Borland Sprint in Windows at one time during the 32 bit era in the manner you described, “passing that Postscript file into another application,” and it worked great. That was a DOS word processor that invited a little hacking, as I recall.

[pjmlp]

Yeah but all of that are ways to workaround the issue that it doesn't actually work without issues, and some clever ideas are required to use it like on its MS-DOS heyday.

[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".

[alejo]

2048 comes to mind as an example of such finished software

[m463]

I played it and hacked it to 4096 with a 5x5 layout so I could play longer. :)

EDIT: I think I took this project:

https://github.com/gabrielecirulli/2048

and modified it

[1vuio0pswjnm7]

As someone who gets paid to find ambiguity in language, cf. being paid to write broken software, IMO the term "finished software" does not leave much room for competing interpretations. It seems quite clear.

As a non-graphical software user, I have been using finished software for many years and I actually prefer it to the broken on arrival variety that has become increasingly common today. The type that can be a Trojan Horse for pre-approved remote access in the form of "software updates".

[Scarblac]

That new versions with new features come out doesn't mean they're improvements on the previous one. At some point it's just bloat that slows down the core functionality.

[eloisant]

even "ls" and "cd" are still getting updates:

https://github.com/coreutils/coreutils/blame/master/src/ls.c

[falserum]

Let me explain to you. Clearly superior example of finished software is from business perspective, where cost of additional development is below projected any additional profits.