Whether or not software can be finished with 0 bugs is sort of irrelevant. Windows and other software users use most will basically never be "finished".

The updates that are causing the fever are not just "bugfixes", they are the current state of living software--always expanding and improving (at least in intent). The fact users see software that hasn't been updated as dead is a reflection of their learned expectations. And they are correct, it likely is dead in the "no longer improving as my other software is" sense.

The real issue I have is how shitty most update processes are. Thanks for rebooting my PC Win 10, yes Sublime Text, please tell me again in a dialog that there is an update, etc. Some apps have done much better here like Chrome and Discord, but it is not an easy thing to build.

The question - and what the article is arguing is about - is if the "no longer improving as my other software is" part makes sense. Does software always have to change (not necessarily improve as software will become worse almost as often as it'll become better - especially when it comes to GUI programs that often tend to shuffle things around, invalidating the users' knowledge)?

I think people tend to memorize how they use software so randomizing / frequently changing your UI is superbly bad, in that I agreeing with your point and that part of the article.

The trouble I still see is that most software is barely held together built on top of stuff that is even worse. From my experience, if it is running on Android or Windows, it is 100% guaranteed you will have an issue you didn't predict because some set of users have done something crazy to their device. I guess you could always leave these things broken for a while, but it would reflect poorly and is hard to convince others that "oh this crash is ok".

I guess tl;dr I think most software is broken and always broken and updating more or less frequently wouldn't really change the brokenness for users, but the frequent updates at least give them hope fixes are coming and their feedback matters. Knowing you'll have this bug forever makes any alternative attractive.

> There is such a thing as finished software. With no major bugs. That does not need constant updates.

The general attitude (both on HN and elsewhere) is that if any security update exists for a product you use then you are a complete moron not to update it immediately. There is virtually no acknowledgment of any nuance on the topic in my experience.

I think this is what people officially say, because this is the "right" thing to do, and in general it makes sense. But in real life things are different. I had to support many ancient systems with no security updates for years or even decades now. For some of them some updates were available, but we didn't even have the hardware to test them on. Yes, we were gradually moving many older parts to newer systems. Nevertheless, in the case of these older machines working in isolated networks, trying to patch them was just asking for trouble. I bet many admins on HN have similar experience.

In other words, people are "virtue signaling"...

Not applying a security update is willingly leaving a known security hole in place. At best, you are making your system insecure, and at worst, you are putting others on your network and/or in your social circles at risk.

or.... You are trying to avoid an update that is going to break your machine/workflow. If security updates were sent along a different channel than feature updates, this wouldn't be an issue. But companies keep tying these together, and there are only so many features you can carelessly break before users become aware of what you are really doing.

If you are not happy with the direction a certain piece of software is heading in, you are free to switch to a competitor that fits your workflow better.

This mentality is what led to Windows XP sticking around long after being declared dead.

If you are lucky to have a competitor. This type of thinking is so naive, I can't believe we still see it pop up every now and then.

I'd like you to expound upon that lack of competition. Where does it pop up?

Android vs iPhone, any website that is moving into a "modern" framework direction. Software that runs MRI's, or CT's. Also any software that is picked by middle management, rather than the people that actually use the software: ADP, Oracle, anything in the education realm, etc.

All software has bugs.

There is no such thing as finished software.

The size of a bug is in the eye of the beholder.

Sorry for the Shellshock.

Edit, took me two seconds to find: https://news.ycombinator.com/item?id=502651. Just as response to http://cr.yp.to/djbdns/guarantee.html

You may be missing the point if the post. Good software asymptotically aproaches bug free over time. Meaning it should require fewer and fewer updates less and less frequently. But reduced frequency of updates is percieved as death of software, and this is actually a problem. I even see it in developers who use it as a metric when choosing frameworks and libraries which is a mistake for older software.

I saw a study done on github where the author wanted to know what languages had the smallest open bug count, and found unexpectedly that c and c++, which are notoriously bug inducing languages, had some of the lowest bug rates of all the languages. His conclusion was that the low bug count was actually due to the languages being used for foudational work, libraries and drivers and such, basically reaffirming the 'many eyes make shallow bugs' adage.

The better metric for if software is no longer being maintained is how responsive is the maintainer to their mailing list/support channel. Regularly seeing requests going unanswered is also likely to show that any updates that happen are also likely ignoring actual user needs.

"Many eyes make all bugs shallow" has been considered an eye-rolling phrase for years now. The reason that foundational C/C++ libs have few open bugs on Github is because they all predate Github and have their own bug trackers, and Github's issue tracker is so anemic (or, more charitably, optimized for small projects) that it offers little incentive for switching.

Addendum: I also believe it is possible to write software that does not need to be "improved". I prefer reliable software more than "dynamic" software that is a constant state of flux. And as you might guess I am not fond of software that keeps expanding with "features" to fill available space. I am quite happy if software just keeps doing what I expect it do, without slowing down or failing. The question I would have as to other users who appear to want updates is whether they want new features or whether they are hoping the next update fixes some specific or general annoyance they are experiencing, e.g., perhaps generally they are not thrilled with the software and hope the "new" or "updated" version will be less disappointing.

While some may think I have misinterpreted the blog author (and I acknowledge this is a valid response), I still think that bug or nondescript "security fixes" is a powerful, fear-based mechanism to compel users to allow updates -- of any kind. And it therefore relevant to any discussion of "updates". Especially when it is common for these bug or "security fixes" to be inextricably mixed with non-security items such as "features" in such a way that the user must except the "whole hog", perhaps in some way similar to "omnibus legislation" in the US Congress.

I respect everyone's opinions whether you agree with me or not. I am just happy to see that some users may be thinking about "updates" and what they really are instead of blindly accepting them without ever pausing to think.

From my perspective every new "feature" that adds code is also introducing a new potential for a bug or security issue. I want programs and systems to get smaller not larger.

A Linux util is more like a program function than a piece of software. The fact that it’s compiled as a separate executable isn’t really relevant as it’s typically deployed as part of something bigger such as a Linux distribution - which is a piece of software that is certainly is complex enough to have bugs forever. “Bug free” software might exist but it’s rare.

The most important thing is that I need to be reassured that if a major bug is discovered in the software I’m using, then it will be fixed. How can I be sure of that? The absolutely simplest way is if the software releases regular updates with very small changes. It’s a heartbeat to let people know there is someone that will solve the future problem.

I don’t even need to install these updates! They are mostly symbolic, that doesn’t make them irrelevant.

Even small UNIX utilities had had many bugs. See numerous man pages with bugs section.