Why the Update Fever Is Bad

Why the Update Fever Is Bad(irrlicht3d.org)

149 points by irrlichthn 8 years ago | 110 comments

sjellis 8 years ago |

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 8 years ago | |

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 8 years ago | | |

There is no software without bugs.

People seem to know that. Developers sometimes do not.

tjoff 8 years ago | | |

Because being maintained is very important for users and one of the easiest and most convincing ways to show that is to release updates.

But then we have the other side, releasing update after update without fixing or responding to common issues. That is quite damaging as well.

mjevans 8 years ago | | |

Maybe for 'trivial' software that can be the case. However for anything complex even if there isn't a problem inherent in the software there are still interactions with the environment which could cause a need for some workaround.

lomnakkus 8 years ago | | |

> Just release when there's something to release.

This emphatically does not work very well for big projects. The problem is human pyschology and the unreliability of all effort estimation processes (in software development). Once people get used to the idea that "well, we'll just postpone the release a little bit" then it eventually becomes a routine thing and for popular projects there's always someone who has a good reason that their particular feature should make it in before the release. (Because who knows when the next release will be?)

The Linux kernel and the C++ ISO standards committee have got this EXACTLY right (since C++11). Predictable releases means:

a) you don't need to rush anything particularly because you know there'll be a new release in N months.

b) any incidental small (not-worthy-of-a-release) bugs get fixed in the interim.

c) downstreams can plan based on when your next release is going to happen.

Predictability is a huge deal and IMO it's incredibly underappreciated just how much it matters. Even if it meant a 10% or 20% 'efficiency' loss (on some metric) I would personally still consider it a win.

For an example of not doing it this way, look at C++ pre-2011 and perhaps also ECMAScript pre-2015. (This is also rampant is development, though no public examples come to mind right now. I'm sure some other commenter can supply some. It's so bad that it can in fact kill projects.)

EDIT: I forgot to mention: Regular updates also means that the "consumer" must get into the practice of regularly applying updates... and will thus become forced to get better at doing that. Ideally to the point of having completely automated updates.

jcelerier 8 years ago | | |

Some people just want to stay home and watch movies and live a tranquil life while others don't feel good if they aren't permanently moving and discovering the world.

muzani 8 years ago | | |

Software is very rarely perfect though. There are some rare cases like Winamp and Photoshop where there's just not much to add.

I do find projects like Dwarf Fortress very charming in that there's an endless supply of new things to look forward to.

kazinator 8 years ago | | |

Here is an example: old wi-fi router firmware that you can't get updates for is vulnerable to problems discovered in the original algorithms, which are correctly implemented in that firmware.

Software can only be as correct and complete as its specification. If that is a moving target, oops!

jimmaswell 8 years ago | |

Literally every time I've let my phone update the Android version, something changed to my detriment - missing feature, not being able to do something a certain way anymore, etc. with the only benefit being the ability to run apps that only target the new version. App updates are often no better.

xg15 8 years ago | |

I think this is part of the mindset the OP is criticizing.

Following that logic, a software cannot possibly be completed - It can be either in development or dead. Which would mean you either have a budget of time, money and resources for constant maintenance of your software - or you might not write that software at all. Repeat that for every new piece of software you want to write.

The problem is that this is impossible to do for hobbyist authors, so we would lose a large amount of free or open-source software currently available.

PatchMonkey 8 years ago | | |

Did you realize that Torvalds did not have anything to do with Linux 2.6.32.70?

He offloaded the whole project onto another team (who mostly backported fixes) that kept it going until early 2016. The rest of us were already in Linux 4.X territory by then.

If you cant maintain it, you can pay someone.

Or, thanks to Github, lets talk about letting the code-literate userbase sort it out themselves. Assuming they care enough.

Or, we could pivot this discussion to the "evils of Capitalism" and whatnot since that userbase probably needs to eat.

asperous 8 years ago | |

There's kind of a parallel with signals regarding businesses as well. There may be nothing wrong with a store that hasn't been renovated since the 90s, but it gives off a "run-down" vibe like it wouldn't be there much longer.

digi_owl 8 years ago | | |

Difference is that buildings etc need to be maintained or else they break down. Sofware, baring weirdness like "bitrot" from unreliable storage hardware, do not break down.

feelin_googley 8 years ago |

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

sholladay 8 years ago |

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 8 years ago | |

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 8 years ago |

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 8 years ago | |

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 8 years ago | | |

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.

digi_owl 8 years ago | | |

Because devs live and breath security. End result is that they develop blinders to anything else.

Also they know when and why to update stuff they work on, thus i never happens at an inopportune time. Nor do they find themselves having to wrangle the new dependency kudzu they created, because for them it built up over time.

martin_ky 8 years ago | | |

I don't think it's the added security, that makes new software slower and less responsive.

Santosh83 8 years ago |

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 8 years ago |

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 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 8 years ago | |

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

anothertraveler 8 years ago |

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 8 years ago | |

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 8 years ago | | |

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 8 years ago |

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

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 8 years ago | |

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

nmstoker 8 years ago |

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 8 years ago |

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

frik 8 years ago |

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 8 years ago | |

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

frik 8 years ago | | |

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_ 8 years ago |

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 8 years ago |

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-...), 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/

bluedino 8 years ago |

>>> 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 8 years ago |

> 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?

Santosh83 8 years ago | |

An appropriately sandboxed process that has no access to other processes or files can be considered non-security critical. But sadly nearly all programs commonly in use can access all the user's data and do with them as it wishes (hence ransomware) thus we have to perforce consider every program as security critical.

throwaway613834 8 years ago | |

> What software is non-security critical anymore?

LaTeX, MATLAB, CMake...

rhn_mk1 8 years ago | | |

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.

awinder 8 years ago |

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 8 years ago |

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 8 years ago |

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 8 years ago |

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 8 years ago |

> 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 8 years ago |

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 8 years ago |

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 8 years ago | |

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 8 years ago | | |

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).

alvil 8 years ago |

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

petre 8 years ago | |

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 8 years ago | | |

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.

rajeshmr 8 years ago |

Excellent, well put!

jlebrech 8 years ago |

maybe nullupdates should be a thing.

sjmulder 8 years ago | |

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 8 years ago | | |

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