The beauty of finished software
josem.co
josem.co
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.
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.
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.
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.
EDIT: I think I took this project:
https://github.com/gabrielecirulli/2048
and modified it
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.
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.
Fair. I should have said "me as a dev" and "me as a user".
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!
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.
> 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.
https://github.com/coreutils/coreutils/blame/master/src/ls.c
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".
BUT (and it's a fairly big But) software does not work in a vacuum. If the software does any interactions with other software, think any kind of networking like email, ftp or whatever, think printing, and so on, then you should expect it to stop working (in those areas at least) at some point.
All network protocols get tweaked from time to time - TLS code changes - Authentication schemes change, I could go on but you get the point.
I've lost count of the number of people who complain to me "but it worked yesterday" - and sure it did - BUT the "world changed and you didn't keep up."
I love finished software - but not all (categories of) software will run forever. Once there is other software involved, then sooner or later it'll likely "stop".
If someone's about to comment with fetchmail, shoo :P
I've never seen that work properly on Windows, it's not end user friendly and I'm not sure how to put "decoupling" better - all I'm saying is that for how email works at least, no, Thunderbird wouldn't necessarily need the means to talk to servers, something local via socket/named pipe/filesystem might be enough - but this would mean more of a paradigm shift and yes, it would maybe also be bad for end-to-end crypto (depends how you define the end, it's still your machine...)
This is the beauty of line-delineated (ha) text-based pipes. I wonder if some of those unix tools would be considered in any sense 'finished'.
Sorry, but when I write a program in 2010, I kind of do expect it to still work on the exact same hardware in 2020. I don't think that's an unreasonable expectation.
This too entails a tradeoff: either the old software sits around in the system collecting defects, or it ends up supported indefinitely and the amount of work required to cut a new OS release increases without bound.
> Sorry, but when I write a program in 2010, I kind of do expect it to still work on the exact same hardware in 2020. I don't think that's an unreasonable expectation.
Unreasonable compared to what? In the abstract it’s not unreasonable but computers are quite an unreasonable environment to begin with. Their capabilities change dramatically every few years, and computers on the internet especially have to withstand essentially constant attempts at intrusion and abuse.
They showed off the powerful GPU of their new M3 yesterday and chose... Myst. Now that is almost comical.
Everybody is over the moon about Apple Silicon, but so far what I see is that we completely lost Windows/other systems capabilities, got even more uncompetitive GPUs than they used to be (if losing windows compatibility wasn't enough, they had to make sure you couldn't play a single game properly) and price and skyrocketed. For what? A better battery life, and a lot of marketing on how things are supposedly faster but outside of video processing they are definitely not if you make equivalent pricing comparison. Power is cheap and ubiquitous, mobile high-performance computing makes no sense at all; external batteries are cheap if they are really needed.
And now you have to deal with annoying software incompatibility, updates of all kinds and re-purchasing stuff that was working just fine before. Some software didn't even get updated and will never because companies have decided it wasn't worth the trouble (they are right).
Sometimes I see some people complain about Windows updates and whatnot. Well, compared to Apple shenanigans, I really do not mind them. I like not even registering on the annoyance scale compared to Apple bullshit.
The amusing thing is that for game development, the most stable target platform is old proprietary video game consoles like the Genesis and Neo Geo simply because there are dozens of emulators for them that run on hundreds of platforms. "Write once, run anywhere" is more true if you program a new Genesis game than make a native cross platform PC game.
Make a PC game, and there's a decent chance it'll stop working after a couple of decades (most Win95 games are already dodgy). People will be making Neo Geo emulators after you're dead. If you make a Neo Geo game, it's going to run on virtually every computer for a very long time.
The real power of it is that it gives you the ability to latch onto the fame of (and interest in) a popular platform. Even if you make an open source game, the problem is that if you didn't program Doom, there's a good chance that there isn't going to be enough interest in it for large groups of people to maintain it over long periods of time.
All things will break in time, though. Eventually, people will probably lose interest in maintaining emulators for arcane systems like that, and your software will stop working then.
Once it's interacting with more than just Windows though then things get less rosy.
But, for a long while now, the forecast has been looking increasingly grim for emulation and software preservation.
That said, if you're targeting the performance envelope of 1990s games, there are options without resorting to anything so esoteric as emulated consoles.
It's frustrating when a piece of software or a library has been functionally "finished" for a long time, but still periodically needs maintenance and updating to accommodate changes that really have nothing to do with the purpose of the program itself. this is probably the one aspect of the Python2->3 complaint that I sympathize with.
Personally, I actually trust the "TLS code" in the proxy, e.g., to be up-to-date and correct, more than I trust the "TLS code" in today's "apps". It's easier to update the proxy, a single program, at the user's discretion, than to worry many different applications, all expected to be free of mistakes and to update prudently themselves.
With the proxy, it's open source so I can do a diff with the version I am using before deciding whether to compile and use a new version.
"Finished software" doesn't mean that developers will spend 0 time on it.
"Finished software" is in the sense of no major user-facing changes (i.e., new product features, experimental features...). To ensure "finished software" continues to run in the coming years or even decades, developers may need to keep up with operating environment changes (e.g., OS, hardware...) & continue to upgrade infra software / libraries for bug/security fixes & performance improvements.
Imagine that a tech company lays off all software engineers except for a few devops.
If I have a 17mm combination wrench, that will work exactly the same way indefinitely. Nobody, hopefully, will upgrade "17mm bolt" to "17mm bolt v2.0" that is actually 17.1mm and make my wrench not fit.
Old software that does a specific thing, simply and standalone, can be a tool. Modern software, with a mindboggling variety of external dependencies, takes real effort to maintain in the "tool" model as dependencies change or retire. Take, for example an old video game that was fully debugged and released on physical media that can still be played (without even a physical machine, on archive.org) the same way. Versus a no longer maintained but treasured Android app or device, which falls behind and becomes unusable. Example: An old Android tablet that the kids use, was able to play Youtube videos. Then, somehow, it updated itself to a new Youtube version that's no longer compatible with it and now it can't, because Chrome has the same problem, and the native browser on there is too old to play web Youtube. Yet the device is still sound, still holds good battery charge and so on.
A bug free game? I wish.
Then one day you need to 17mm socket wrench.
A year later, you find yourself needing a 17mm deep socket wrench.
The year after that, you've got a scenario where the deep socket wrench would work, but requires a cheater bar, and there's no space, so you need a drive adapter to connect it to an impact wrench.
The following year, you start working on a vehicle where torque matters, and you need all of the above tools to work with a torque wrench.
6 months later, you realize you got a torque wrench that only goes up to 80 (units-of-torque) and now you need 100.
----
The difference with physical tools is that nobody will raise an eyebrow at you having all these variants of your 17mm wrench. By contrast, having all these variants of (to use TFA's example) a word processor would seem quite odd.
Your other examples are a bit weird, because you're changing it from a wrench to a socket wrench. The interface is quite different:
Wrench -> Bolt
Driver -> Socket -> Bolt
Not to mention, all of your other examples illustrate that there's a perfectly fine interface between the 17mm socket and all of the various ways to drive it. The 17mm socket is complete software.
The owner of a 17mm combo wrench starts out with what appears to be the perfect tool for the job, but then comes to understand that the scope of interacting with a 17mm nut or bolt is wider than originally understood. They end up with a toolbox that is much more complex when it comes to "interacting with 17mm nuts and bolts" than they originally expected.
And so it goes with software too, not always, but extremely often.
that one time my toilet stayed the same for 5 WHOLE years, but you know, there are totally toilets with bidet's, toilets that are motion sensored, tall toilets, short toilets, toilets meant to squat over, ad nauseum.
so for this reason it's totally ok for YOUR toilet to need be replaced every few months! yeah, that conclusion absolutely follows from the premise.
or not, and maybe the other posters point is that there being other needs and variations doesn't mean a specific tool for a specific needs must always change.
More than that, most users of most sophisticated creation software have their own evolving needs, unlike GRR Martin and his word processing requirements. The program they needed last year, before their understanding of their own process and their own aesthetic goals expanded, isn't the program they need this year.
I had to transition my tools from imperial to metric in the early eighties.
The web and mobile both enable a cycle of extreme optimization where ad-based or subscription-based models are continually squeezed for every last dollar of possible value. This is why if you’ve worked at a tech company that is thriving, a ton of your work just goes poof over time.
The best modern pieces of finished software I use are either free, donation-based, or a one-time paid price. My favorite modern app like this is a little utility called Simple Pacer, which solves distance, pace, or time calculations for runners. https://apps.apple.com/us/app/simple-pacer/id1273474255 It’s perfect and the version history on iOS is sparse. I’d bet it makes only a little money though.
open-source-available minimalist zero-dependency projects that you can fork, fix and compile in 5 minutes.
Sometimes I play old PC games with Wine that are the exact same executable they were 20 years ago.
It is hard to describe but it feels strangely calming, you just know everything is still the same as it always was.
Emulating X86 on ARM/Risc-V is an abstraction tree I don't want to climb f.ex.
Wine hides that power consumption.
It's a false sense of security.
I'm the opposite to you though, rather have an original C64 on modern capture (low latency GV-USB2) and (S)NES classic controller input.
And running old software on modern hardware often uses only a fraction of the power the old hardware used to need. If one cares about power consumption, modern software has become so much worse.
We often discount progress as obvious because we never paid the price of photosynthesis for millions of years before our tiny part in existence.
My problem is specifically getting to the consensus we have today, we were too slow, 6502 (8) freed humans 1982-85, 68000 (16) and ARM-1 (32) came 1985. So we had the instructions (in both senses) for the final hardware then.
40 years, and X trillion barrels of oil, later we are still in complete hardware and software confusion.
64-bit is a big mistake, because nothing scales to infinity; and since nothing is free, we are about to pay the price now!
Indebted to the past and the future to max!
I say roll back to C and Java and rebuild from there on Risc-V (even if it has 128-bit addressing, in case you run out of your 18.4 exabytes 64-bit RAM/disk).
But it might already be too late.
>64-bit is a big mistake, because nothing scales to infinity; and since nothing is free, we are about to pay the price now!
What?
Also would need more cores, SRAM and some OpenGL ES GPU! ;)
Wait, huh? Are we thinking of the same Starcraft? Is there a different program or utility with the same name as the videogame? Because the videogame was absolutely not a single-person creation.
It's still a very impressive technical achievement to rewrite a game engine like that, I just don't think it qualifies as "finished software" in the way this thread intends that phrase to mean...
edit: in fairness your post wasn't talking about finished software per se; I still feel it's inaccurate to call starcraft.exe a one-person creation.
While these are deliberate design decisions, a nice benefit of the iOS ecosystem is that the app has kept working on every new iOS version without me updating anything in the code. Things like installation flow, payment processing, etc. are definitely components that would fall apart a lot sooner when not offered by the platform itself.
Sure, platform lock-in and all that stuff, but so far the app just keeps generating happy users every month (and some pocket money).
I have received literally daily warnings that the app will be delisted if I don't fix a laundry list of issues including security vulnerabilities, outdated libraries, new EULAs, Icons in different sizes, etc. Despite all of that the app is still there and able to be downloaded (just checked).
Their version numbers converge to π and to e respectively when bugfixes are delivered, and will become precisely π and e when Knuth passes away.
Also, whoever decided that highlighting something should try to guess the whole words you wanted and when copying should throw a space on the end for no apparent reason should be, well... I shake my fist at you. I spend a lot of time re-highlighting something either to avoid the space on the end or the beginning or both or to get something out of the middle of the word and it's incredibly frustrating. Just stay out of my way. I've got this.
I'm curious why you don't turn those features off
I think it's important for people to realize this is totally untrue. You can check the wikipedia for wordstar[1] and the first paragraph says, "...originally written for the CP/M-80 operating system, with later editions added for MS-DOS and other 16-bit PC OSes."
Software needs to have the ability to change because the devices we run it on keep changing - either because we make new ones or the old ones wear out. This is why open source is so critical - because there is no such thing as "software you can use forever," there's only "software you can use right now and modify to continue to use in the future."
That said I also appreciate software whose feature set is frozen - allowing it to quickly and easily be made available on many platforms and be immediately usable by anyone who encountered it before.
Need to differentiate between finished FEATURES and finished software.
All these ideas have been there for a long time. But they work only if nobody wants to earn money with the software development.
The big gap in users is between "computer familiarity" and "computer proficiency". People associate environments with home, and the older the enterprise user base is, the more they want their mouse menus and clicker buttons. Introduce a text interface, say so long to 90% of the enterprise users . . even if the windowed equivalent is a hellish nested circular menu labyrinth no one can use the same way twice running.
While the days around 2003 when the project had +2500 commits per year are long gone, coreutils is still fairly active, with ~200 commits per year.
Even looking at really simple tools like 'yes', git blame shows a bunch of fairly recent changes.
On commands with specific repository like grep (https://git.savannah.gnu.org/cgit/grep.git/log/), the project actually peaked not too long ago, in 2010, with 355 commits a year. And the current activity levels (82 commits 2023) are not that far off this high.
Of course, commits are not everything. I expect the actual code changes to be smaller (lots of 1-5 lines fixes vs ~100 lines new functionality). But these tools are still evolving quite significantly.
I propose calling this idea Uniquely Minimal Individual Extensions, aka UMIX philosophy, and creating a suite of small self-contained programs that can be flexibly composed to create more complex ones.
- Ecclesiastes 1:9
Yet it receives consistent updates finding smaller and smaller fixes and refining the game even more. How do you reconcile those ideas?
It's possible I've got the wrong takeaway from this article.
cd ws
wsYouTube was already a great video sharing and recommending website in 2005, but if it still looked like this, it would be dead.
https://www.youtube.com/watch?app=desktop&v=C-JrfjVjHAY
It has crazy stats: 18 years old and only 3.7K views!
I wonder were the compression artifacts this bad when the video was uploaded or has it been recompressed a bit too many times? Still groovy tho
I have uploaded my first YouTube video in October 2006. The quality is still as day one.
However, some comments seem to have disappeared. I can only see my reactions to those comments.
Not true. We accept that physical products WILL change due to wear and tear, repairs, and even deliberate modifications. It's true that car pedals will stay in the same position, and a table will keep having four legs, but their parts WILL be replaced. Physical products can also have bugs, hence the recall campaigns that happen now and then.
Software just makes it easier to replace and modify, and open source allows more people to do that. It just happens that software runs on a physical product (a.k.a. hardware) that has a much lower need for maintenance than a car or a piece of fabric, so you can use it for longer if that pleases you.
Software can still be developed iteratively. That's not the problem. With CMake, for example, I don't 'fear' upgrades, because that team values the idea of 'finished' software. As does Microsoft.
On the other hand, the NPM and Apple dev teams do not cherish this idea. And in turn, both their user and developer communities suffer in the long run.
That's how I've come to see it recently.
> cd command implementation does not change.
I'm pretty sure the cd implementation needs to interface with different file systems. Those interfaces change or at least new interfaces appear when new file systems emerge.
> The word processor does exactly what it needs to.
What we use a word processor for, changes over time. Does the print function still work for my inkjet printer, in A4 format? Can I write emails with it, why should I even use the word processor if my email client has an embedded word processor? Can I embed images, only TIFF maybe?
Unfortunately there is no such thing as forever software, unless you don't change the circumstances in which it is used, which is very unlikely.
TeX would be one such example which reflects its converging nature in its versioning scheme. But I think it applies to a lot of other software - e.g. basic GNU utilities like grep, awk etc. are like that.
Also, how do you handle locales - "Bonjour le monde" and "Hola Mundo" should be table stakes for an actually finished hello world program.
If you wrote it in C, I wouldn't be surprised that in a few years time you'd have to check a few security policies before you can actually write to the stdout file descriptor. And in JavaScript, the top level "console" object will probably be removed to avoid possible namespace clashes.
https://www.cs.drexel.edu/~yc349/CS451/RequiredReadings/Soft...
Software being finish-able shouldn’t be a fringe belief. The fact that it is really explains a lot about tech.
Now, I'm using it every day and haven't changed it in years. It compiles everywhere even on my M1 with Asahi Linux.
All my other software is not beautiful. It requires changes.
From the WordStar Wikipedia:
> no current version of WordStar is available for modern operating systems
https://www.theregister.com/2022/06/28/friday_foss_fest_runn...
[2] Run WordTsar:
It does what it's supposed to. Receives MIDI messages; changes programs; lets you edit and save; does the SysEx dumps and restores.
It does not make any sense: it is fake work while there is so much real work to do.