If that's true, how do you explain the observable pattern of many consumer applications degrading in UI functionality and coherence after a certain point?
> But also, just use the old version if it's finished, you don't need to upgrade?
Exactly. I reverted to 0.12.
Most consumer software in developed under the assumption that features only have a cost when being built. Their maintenance cost, and the combinatorial complexity each new feature adds, is barely considered. As a result, software teams add complexity at a speed that exceeds the rate at which the team's size, and the volume of work it can handle, grows. Eventually this reaches a critical threshold and the quality of the software starts to decline. But this doesn't mean the software couldn't still be improved, just that there isn't the resource available to do so.
I suppose that's true, but I don't see what it has to do with UI design from a usability standpoint.
> But this doesn't mean the software couldn't still be improved, just that there isn't the resource available to do so.
It's a push and pull from both sides, isn't it? The accretion of process complexity among the developers may increase over time, but so too does the completion of core features and solution of all of the low-hanging-fruit development tasks.
Pretty much every GUI application I've ever used seems to hit a point where the original purpose for which the software was devised is satisfied for essentially all common use cases, but the incentives of the dev team are to keep going, so they move more and more toward gimmicky features, unnecessary bells and whistles, visual changes to the UI, etc. because any real functional improvement is a big investment, but they still need to justify a new release.
UI churn is one of the most common failure modalities here: when you've already picked all of the low hanging fruit in functionality and performance, major UI changes can create the appearance of improvement and innovation without actually having to do any of the hard work to achieve real improvement.
So when I see unnecessary UI changes to an application that still basically does the same things in the same way, at this point I'm conditioned to assume that that application has hit the point of diminishing returns for actual functionality, and the development incentives are now going to be driving more and more churn. And that's when I consider the software "finished".
Well, that's easy: Bad choices. The better something is, the easier it is to change it in a way, that makes it worse.
I agree with GP, everything can be improved, but that doesn't mean that you will succeed, or that you should try, for various, separate reasons.
The point at which new changes are more likely to degrade an application that's already excellent for its established use cases than they are to improve it further is the point at which we should consider the software "finished".
There may be lots of theoretically plausible improvements that could be made, but if the constraints of actual practice make pursuing those ideas a net detriment, that's probably a good place to stop.
I think AI may actually make this simultaneously better and worse: it will eventually be really easy to hit all of the functional and performance targets early on, so "finished" software will at some point be much better and closer to true completion, but the mentality that drives people to keep fiddling with it instead of moving on to a new project will be just as prevalent, and the post-"finished" releases will likely be even worse.
What I think: Being finished is not a property of the software. It's a function of skill of the maker to spot true opportunities to improve things, the skill of the maker to understand their own limitations to implement stuff (time, money, skill), and the current state of the software as it relates to the world.
It requires ongoing judgement and taste. If any of the inputs change, as they do, the answer changes.
When things get super trivial, you can probably consider them done at some point, but I hesitate. Let's for example just consider "cd" (the shell function). A typo like "cd /home/user/projcts" could offer a smart correction. If you went to "/home/user/work/clients/acme/backend/api" previously, through better usage of nav history you could maybe just get there by using "api".
Not claiming these off the cuff examples are great, and that they might not survive additional consideration, but it's fairly easy to see that they are arguable (and implementations like these already exist in some tools)
SpeedCrunch is much more complex and very far from inconceivably improvable, in my opinion.
Sadly they think they are making it better. Most of the time chasing fads.
Sometimes introducing dark patterns, for reasons.
I mean, Apple (and MS) had been dumbing down their OS in the name of usability and security for a while now.