
Why the Update Fever Is Bad - irrlichthn
http://www.irrlicht3d.org/pivot/entry.php?id=1562
======
sjellis
Software updates are a kind of project heartbeat. The content of them is less
important than the signal, "this project is still alive, and maintainers are
fixing issues for people". If a project does not put out updates, then users
may (understandably) worry that if they have an issue, it won't get addressed
promptly.

I actually don't think there is anything wrong with having time-based
releases, and putting very little content in some of them. If you only fix one
bug in a quarterly/bi-annual release and tweak some docs, because that's all
that's needed, you have still fixed an issue for somebody, and demonstrated to
all of your other users that you are still keeping your commitments, and there
for them if they need you.

~~~
chii
But on the other hand, if the software is stable and no longer needs updating
why force small inconsequential changes just to appear to be maintained?

Just release when there's something to release.

~~~
MrQuincle
There is no software without bugs.

People seem to know that. Developers sometimes do not.

~~~
gizmo
There are projects that are close to bugfree, though. You can use a 3 year old
version of sqlite without any difficulty. I don't know what version of "ls" or
"mkdir" my machine runs, but I never worry about these simple utilities being
out of date or behaving differently in release/staging. These utilities are
essentially done, and 30 years from now they'll still work fine.

There is no software without bugs in the same sense that there exists no
hardware that cannot fail. But you can create software that is so close to
perfect that hardware failures outnumber software failures 100:1, so there is
no point in pursuing perfection any further.

~~~
ken
SQLite is not typical software. It has over 90 million lines of test code, and
is run in production every day by pretty much every computer in the world.

mkdir(1) is also not typical. Excluding the copyright header comment, it's so
short that it fits entirely on one screen. If I ran into a bug, I could
probably find it and fix it (or write my own version) in about 3 minutes.

It is indeed possible to "create software that is so close to perfect that
hardware failures outnumber software failures 100:1", but it's so time-
consuming that almost nobody ever does it.

Version 1.0.1 of a free mind-mapping app may be good and useful software, but
I can virtually guarantee it has bugs. I doubt even the author would claim
it's only at 1.0.1 because "there is no point in pursuing perfection any
further".

~~~
cesarb
> mkdir(1) [...] it's so short that it fits entirely on one screen.

296 lines in the main .c file, without counting the headers and helper
functions:
[https://git.savannah.gnu.org/cgit/coreutils.git/tree/src/mkd...](https://git.savannah.gnu.org/cgit/coreutils.git/tree/src/mkdir.c)

~~~
carbocation
And, entertainingly, it contains a FIXME!
[https://git.savannah.gnu.org/cgit/coreutils.git/tree/src/mkd...](https://git.savannah.gnu.org/cgit/coreutils.git/tree/src/mkdir.c#n256)

------
feelin_googley
Glad to see this being written.

"Trained" is the word I have thought of many times as well. It is perplexing
to see people wanting updates.

It is possible to write finished programs that are bug-free[FN1]. But when
eternal rounds of patching becomes a religion, what sort of standard are
developers promoting? Every program is expected to have security holes that
will need to be patched? What about not releasing software unless it is safe
to begin with? Why does a liability need to be created? Solve the problems
before the software is released. Not after. Can't solve them? Then do not
release.

Automatic updates are also a security hazard in the same way as "antivirus",
which also trained users to want updates. It is a backdoor that users are
advised to leave open.

FN1. Inevitably there will be the HN commenter who repeats some meme that says
all software has bugs. True perhaps if we forget about Ada and the world
outside of MS Windows, but are all the bugs major ones? Consider the stuff you
find at [http://cr.yp.to](http://cr.yp.to). Or many of the small UNIX
utilities. I could name more selected examples. There is such a thing as
finished software. With no _major_ bugs. That does not need constant updates.

~~~
throwaway613834
> 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.

~~~
dvfjsdhgfv
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.

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

------
sholladay
People expect their software to improve over time, and thus receive updates,
and this is perfectly reasonable. Most software is never "done". If it is a
small module written in a highly mature language and operating in a stable,
slow moving ecosystem, then fine. In those cases, simply document that updates
will be few and far between and that this is expected for the above reasons.

More likely, development simply slows down because the maintainer got lazy,
moved on to other interests, or doesn't have time for other reasons. Users
don't like this and they are right to worry that the maintainer may be
unresponsive or that the software will not be quickly patched in the event of
a security vulnerability being discovered because the software is not actively
maintained.

Your software is not complete. It is merely functional. In fact, it may not
even be functional, as the rest of the world moves on without you and your
code rots away.

~~~
blincoln
Counterpoint: I've written a lot of niche utilities over the years. Some of
them are very simple, and some of them are very complex. They're specialized
enough that in most cases, they are the only software that performs a specific
type of work.

To my knowledge, they all still do _exactly_ what I made them to do. Are there
things I would like to add to some of them if I had unlimited time? Yes. Does
_not_ having time to do that mean that they've stopped doing what they were
designed to do? No.

The only time I can see an argument for frequent updates being _required_ (as
opposed to a bonus) is for software with direct dependencies on other things.
youtube-dl, for example, or the NTDS.dit-extracting functionality in Impacket
are good examples of this - they work directly with content that may change at
any time, so someone needs to make sure they're compatible with the current
versions of that content.

------
JeffL
I stopped letting my iPhone update. I swear every update makes it slower and
buggier. My old iPad which was perfectly fast and great at the time is now
almost unusable after 4 iOS upgrades. It won't even play Sudoko without
constant mini freezes.

~~~
5ilv3r
People would rather use a functional but insecure tool than a broken secure
one. No question. It's hard for devs to understand that for some reason.

~~~
timrichard
My iOS device is noticeably laggier too, and I find it difficult to point the
finger at security fixes. More likely the bloat from a load of features that
nobody asked for.

------
Santosh83
I guess if your software is stable and 'finished' enough not to be updated
often then it would be good if you have an established communication channel
(like a website or a GitHub page) that will periodically come out with, well,
'news updates', since it _is_ true that most users are conditioned to expect
some kind of update/activity surrounding their software.

Besides any moderately complex software will probably have enough bugs to
require updates now & then for years, even if no new features or added. Not
only bugs but often the underlying platform changes/breaks, needing
workarounds or rebuilds.

------
eadmund
This is something I see with Common Lisp libraries a lot. Many of them look
abandoned, because they've had no updates in years. But they're really not:
they each aimed to do one thing, they each do it well, and they don't have any
more (notable) bugs. The Lisp spec doesn't change, so if a library's
functional spec doesn't change … it's complete.

E.g. [https://github.com/dardoria/uuid](https://github.com/dardoria/uuid) a
library to generate UUIDs: once it fulfills the spec properly, it's
essentially done. This particular example _could_ contain a bug, of course,
but the principle stands.

~~~
watt
It does not even have a readme. What kind of definition of done is this?

------
anothertraveler
I gave up on Windows about 10 years ago. I've had to use it for work
sometimes, but the Windows Updates are actually destructive sometimes, and
often take hours to install during business hours (especially if you happen to
need to reboot before an important meeting...). I can't handle uncertainty in
Software, and I think that many business are losing productivity because of
this. Or maybe IT support departments are happy to keep themselves employed.

~~~
digi_owl
Sadly the Linux ecosystem (baring the kernel and the GNU supplied coreutils)
do not seem to do any better. And from what gather, Apple is notorious for
breaking things as they see fit as well. Not sure how well the BSDs do in this
regard.

~~~
anothertraveler
I am a Debian sid user, so I know well what you mean, but as long as you don't
do a kernel upgrade, Linux has been extremely stable for me. This wasn't
always the case. 10 years ago, Debian sid would break all the time, but I have
probably had only one or two non-kernel/driver related issues in the past 5
years.

Another subtle difference is that on Linux platforms, you have more control
over when/how to update, as well as visibility into exactly what is updating.
I'm sure it's visible on other platforms, but I don't have to worry about
rebooting my machine and having to wait 2 hours for it to come up.

Perhaps another point worth mentioning, LTS versions of Linux distros (Debian
stable, or Ubuntu LTS versions) mainly get security patches, and, optionally,
back ported software. That makes your OS stack super stable!

I'd put kernel upgrades into a different bucket... but most _users_ don't need
to update their kernel on a daily or even yearly basis except for security
patches.

Great point about coreutils too! No need to update ls and grep...

------
jodrellblank
This doesn't say much about why it's bad. Colin Percival wrote a more detailed
piece on updates, their problems and considerations here:
[http://www.daemonology.net/blog/2017-06-14-oil-changes-
safet...](http://www.daemonology.net/blog/2017-06-14-oil-changes-safety-
recalls-software-patches.html) and suggests separate channels for 'updates'
vs. 'security fixes'.

 _This is something new for Microsoft: Usually they won 't break their own old
software with updates, they are known for keeping up backwards compatibility
at all costs._

It really isn't. Thirteen years ago:
[https://www.joelonsoftware.com/2004/06/13/how-microsoft-
lost...](https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost-the-api-
war/)

 _If you ask the users about it, they don 't even know why they want these
updates. Is there a feature they are missing?_

New things are fun. Maybe there'll be a feature I don't know I'm missing until
I see it. I'm hankering for you to amaze me and fix all my problems. Be my
Holy Grail of (text editing, browsing, productivity, databasing, developing,
life ...).

~~~
digi_owl
New things are fun when you are young. As you grow older you learn to
appreciate stable reliable behavior.

------
nmstoker
With such a huge spectrum of kind of software, what applies in one kind won't
necessarily be so for another.

The heartbeat argument is an obvious case. It's the same reason people look at
the UI "chrome" in the screenshots in Android Play Store - if the battery
indicator is from Eclair it doesn't built confidence it'll work in Nougat!

But that may apply less to a more minimalist utility (eg a command line tool)

Merely to update it so that you formally confirm that this version was tested
on newer systems may be valid in some cases (although one could merely update
documentation in many cases for that).

And then there is the dependency argument. Where a tool directly contains
underlying packages, it builds confidence the developer won't get stuck too
far behind current(ish) versions (with the greater risk of it becoming
abandonware). Where the dependencies are external (ie up to the user to have
installed) you do not want to be stuck on some old version, as other tools may
move on, even if this super-stable software doesn't feel the need.

------
nautilus12
I agree with this to a certain extent. If more care had been put into the
software to start with then they should need frequent updating. And often bugs
can be introduced with an update of a dependency for example, because you
cannot be sure that all your dependencies are preserving backwards
compatibility. Usually it goes something like this, inconsequential dependency
has a security vulnerability that needs updated, that requires two other
dependencies to be updated, the third one is pretty hacky and has a latent
bug. Software is updated, but over the next month three more hotfixes are
needed to address the bugs by the bad dependency. Thus the software lifecycle
continues on. Btw, I thought this article related to this was really
interesting: [https://www.siliconrepublic.com/innovation/darpa-working-
on-...](https://www.siliconrepublic.com/innovation/darpa-working-on-software-
that-doesnt-need-updates-for-100-years)

------
frik
Show them somehow it is still supported, update the minor version or
something.

In general:

If I come across a 3 year old binary, and no news article about dev activity
it looks "dead and unsupported". Also on GitHub, if there is no commit for 1+
year, it looks "dead and unsupported", piling up of Github issues is also a
bad sign. Using "dead" binary asks for troubles down roads, when you want to
use it in a few months and it stopped working.

~~~
taneq
Binaries (without external runtime dependencies) generally don't just "stop
working" like that unless you change something significant about your system.

~~~
frik
Ideally yes, but the world changed. There are a constant stream of updates for
your OS, graphic card driver, etc which constantly break things left and
right. If it affects a big software, even an outdated version) the user outcry
will make sure it get fixed. But you better make sure not to rely on an
unsupported 3 year old rather niche software if you plan to upgrade anytime
soon.

------
_ph_
If a software is under active development, one would at least occasionally
expect updates with new features and enhancements. Even if it is just in
maintenance mode, there would be bug and security fixes. Not every week, but
at least every couple of months. With software like iOS apps, it is a huge
warning sign, if apps are not updated after OS updates or especially after new
devices introduce new screen sizes. And with iOS, those apps are eventually
going to stop working.

------
aiNohY6g
It's not like we always have the choice not to upgrade, either because of
security (IoT anyone?), because one of the giant's shoulder a software has
been built on has gone wild or has its own security fix to deploy
([https://github.com/blog/2470-introducing-security-alerts-
on-...](https://github.com/blog/2470-introducing-security-alerts-on-github)),
or just because updates are automatically installed and it's too late when you
realize it's broken :-/

Edit: Android devices does not suffer from this fever, btw. How good. Really.
[https://danluu.com/android-updates/](https://danluu.com/android-updates/)

------
bluedino
>>> Is there a feature they are missing? A specific bug they want to have
fixed? They don't know. They only want updates, because they are used to it.

A long, long time ago DJGPP 2.0 was released, and almost immediately people
were asking when version 3.0 was coming out.

It was a DOS port of the GNU C compiler, so really you can't make a new
version of it until the next GCC comes out. Plus, the question was, "What
would the update have?"

It's not like commercial software where you need to add features every quarter
so your competition doesn't leave you in the dust.

------
cwyers
> So for non-security critical software, it is sometimes better not to update
> that often. This update fever is bad both for developers and users.

What software is non-security critical anymore?

~~~
throwaway613834
> What software is non-security critical anymore?

LaTeX, MATLAB, CMake...

~~~
rhn_mk1
Terrible examples, considering that these are programming languages that
people will use to run code from random sources.

"git clone foo && cmake foo" can definitely be a security problem, and not
just because the code itself is untrusted.

~~~
saywatnow
It's not cmake's job to limit the behaviour of programs written with it.

~~~
al2o3cr
OTOH, allocating & using memory correctly so that a maliciously-crafted
Makefile can't get elevated permissions _is_.

~~~
pedrocr
A makefile can call whatever it wants so if you run a malicious one you're
already hacked. There's nothing you can do with a cmake buffer overrun that
you can't also do just by writing a normal cmake file to call out whichever
malicious commands you want.

------
awinder
A lot of commenters have keyed into the product heartbeat line. Shipping
updates is one common signals of a healthy product but it’s not the only one.
If your product has non-user-facing changes, you should try to make noise
about what other people are actively building or doing with your product. Or
if you’re offering a service, market reliability and put time into showing
stability and educating customers on why they should trust that they can build
with you. You should also be working on acquiring customers if your product is
in that phase. Realistically you’re talking about a product that requires
little to no maintenance for existing customers which should free you up to
spend time getting more customers.

Any of the above is going to realistically create feature work as you work
with new customers or users and find further areas for completing your product
offering.

Word of caution — this work will never realistically end, or you will end.
There is no end state to software. Software is the tool, the product is your
user or customer community and the problems you solve together. If you’re
looking to build software as an end state, I see obvious problems, and your
customers do too.

------
ilaksh
BTW Irrlicht is great so thank you to the author for making it. CobberCube
looks good too. But that is one reason someone might not update a project a
lot -- they are making other stuff, for example one along the same lines that
could make money. But Irrlicht works great still and still has a forum etc. so
I would not complain if there weren't more updates.

Actually I wouldn't really want another update at this point, because I
already have a code base built on the existing thing that does what I want and
adapting to new/changed stuff would distract from developing features specific
to my system.

------
martin_ky
I don't know if it's just me, but I have to exert significant energy to
convince (typically) new hires, that it does not really hurt anything if we
use older versions of some dependencies, as long as they are stable and we are
not hitting any bugs or vulnerabilities. In other words: it is not reason
enough and not worth to update only because a new version was just released.

Such discussions usually end in one final argument from the new developer:
"But your version is no longer maintained!"

------
ChuckMcM
Interesting debate, updates as a product viability signal.

I can see the angle as a developer that there isn't anything new this
week/month/quarter in the software. And I can see the user angle that if it
hasn't been updated perhaps updates are no longer available.

That makes me wonder if an update that says the software continues to be in
good shape (a non-update update) would assuage the user. Something like that
could be automated and so not impact the developer.

------
oconnor663
> Is there a feature they are missing? A specific bug they want to have fixed?
> They don't know. They only want updates, because they are used to it.

That doesn't sound like the most charitable reading. A lot of customers expect
updates to mean performance improvements or security fixes, neither of which
they'd be able to ask for with any kind of specifics.

------
jimjimjim
Tail wagging the dog.

If it needs a fix, update it.

If you want to increase awareness, add a feature.

If people are paying a software support fee or have a contract stating a
certain number of releases a year then do releases.

Otherwise why risk introducing new problems

------
bugmen0t
I wouldn't call myself very experienced, but software is really brittle and
everything is built on top of something else, so an update triggers an update
triggers an update..

~~~
jakobegger
But there are other ways to build software. You can make apps with very few
dependencies, use stable APIs only, program defensively, make sure you
properly read the docs and handle all error conditions, don’t add unnecessary
features, etc.

The result can be an app that requires minimal maintenance and it might work
for years without any changes at all.

~~~
digi_owl
But doing so takes focus and diligence, something the software world is
notoriously short on (likely they can always push another fix to prod, unlike
with hardware).

~~~
timrichard
And it wasn't always like that with software. We're used to the current
situation in the age of portable devices and app stores, but I remember buying
software in the 80s and 90s when most people didn't have a modem or any
networking connectivity on their home machines. You went to a store, and
bought software on disk or CD that came in a cardboard box shrinkwrapped in
cellophane. You tried out the features, and it either worked or it didn't. And
if it didn't, you were stuck - but that generally didn't happen, to my memory.
Because of the lack of options when the product was on the shelves, it was
tested rigorously. (Of course it would be fair to say that it would be a
siloed runnable that wouldn't generally have dependencies or be required to
interoperate with anything else, but the feature density would be comparable).

There was none of this "fix it in tomorrow's release" from the "just ship it
duuuudes", so you didn't find obvious defects in features within minutes.

------
alvil
Do fake update at semi-random time. Visualize it, eg. show them a dialog with
progress bar and percentage.

~~~
petre
Thus wasting other people's time and productivity?

I'm using the Atom editor. It's kind of annoying how it pushes new updates
every week. Previously used Subline Text 2 which just worked and did not have
an update for years.

~~~
sicher
Sublime is a great example of users getting update fever. The forum is riddled
with long ”is this software dead?” threads that pop up at regular intervals.

~~~
empath75
Eventually it will be, if they stop updating it. Atom and visual studio code
are overtaking it.

------
rajeshmr
Excellent, well put!

------
jlebrech
maybe nullupdates should be a thing.

~~~
sjmulder
For anyone thinking about doing this, here are some free release note
templates:

"Bug fixes and stability improvements"

"Thank you for using <X>! For your benefit, we update <X> continuously. Every
updates for <X> potentially includes new features, bug fixes and other
improvements. Don't hesitate to reach out to noreply@<X>app.com if you have
any questions or suggestions."

"Bedankt dat je <X> gebruikt! Bij het invullen van de releasenotes heeft onze
stagiair niet opgelet en per ongeluk de verkeerde taal geplakt. Geen probleem.
We hopen dat je van deze nieuwe versie geniet!"

(For the longest time, the Dutch Facebook Messenger app had release notes in
some Scandinavian language.)

~~~
mizaru
A lot of popular iOS apps are doing this, which I personally find extremely
annoying.

~~~
obmelvin
I would reckon that the average user doesn't care for a list of specific bug
fixes.

