Every single time I open your software, I'm asked to download an update
I have this experience with a few apps I use sort of infrequently. Most of the time the upgrade feels pointless. Anyone else? Why does this feel so common nowadays?
50 comments
Firefox is really annoying in that it just breaks an already open session because it's been updated in the background.
So instead of just waiting until you restart firefox, it forces you to restart it RIGHT NOW, usually in the form of showing a bunch of "GAH! This tab just crashed!" pages that crash over and over if you click the retry button.
Only when you try to open a new link in a new tab does it tell you what's really going on (with an annoying cutesy "We just need to do one more thing" - Well FU do it later, I'm in the middle of something!). Doesn't matter that you'll lose work if you restart now - you're just screwed. It's like Microsoft forced update, only much, much worse.
And then once it restarts and you try to pick up the pieces, you discover that it loses the last tab you had open, so you have to remember what it was and then use a search engine to find the site again.
So instead of just waiting until you restart firefox, it forces you to restart it RIGHT NOW, usually in the form of showing a bunch of "GAH! This tab just crashed!" pages that crash over and over if you click the retry button.
Only when you try to open a new link in a new tab does it tell you what's really going on (with an annoying cutesy "We just need to do one more thing" - Well FU do it later, I'm in the middle of something!). Doesn't matter that you'll lose work if you restart now - you're just screwed. It's like Microsoft forced update, only much, much worse.
And then once it restarts and you try to pick up the pieces, you discover that it loses the last tab you had open, so you have to remember what it was and then use a search engine to find the site again.
I prefer the Firefox solution. Chrome "solved" this by running the outdated version untill restart. But if you click a link outside of chrome it opens in a new instance of the updated version, without your old tabs. If you at this point close all chrome windows then you've lost all the tabs on the outdated instance.
I use Firefox ESR to avoid every little update, but still get security updates. I also set Firefox to notify me about updates, but not install them unless I choose to and only once has Firefox disrespected that setting and pushed something at me without any prompting. If I ever figure out how they pulled that off, I'll do whatever I can to disable that too.
I've never had that happen on Firefox for MacOS or Win11.
It's when a package manager updates Firefox while it's running.
Agile cargo cult software development there. Got to get that 4 byte change in this sprint in order to prove that the team's fantasy points are burning down.
To game this, I have started literally splitting tickets into two: 1) implementation and 2) rollout.
This sometimes even lets me present the same win for two sprints.
This sometimes even lets me present the same win for two sprints.
Uh oh sounds like someone is due for hours of alignment meetings defining “definition of done” :p
We had those, multiple times. Our Jira tickets now contain a DoD checklist no one ever ticks something on or checks. We have just stopped talking about it.
I was just being sarcastic but yeah that’s basically what happened in some of my old teams too.
I occasionally play video games to relax, either firing up a PC I only use for gaming or a console. Every single time I've done that lately, I've had to spend at least 10 minutes downloading and restarting to get some updates before I can even try and launch a game. Makes for a frustrating experience when the rare chance I have to have some fun feels like work.
I've been needing to vent about this. I have two kids and we play Minecraft, Starcraft, and other Blizzard games and Steam games, on the LAN; we have several computers, both Macs and PCs, in the household. The amount of "updating" that happens is absolutely insane. Blizzard games update themselves multiple times per day (I read somewhere that if it is updating this much, it is a bug and you should do a clean install or something, but it has always happened on all computers no matter what). All of these games have launchers, and the launchers also require updates, and even if you are playing single-player or on the LAN, you have to take the update. You have to sign in with your username and password. You have to use a different account, with a different email address, on every computer. I made the mistake of buying two iMacs with SSD/HD fusion drives for the household, which use very slow HDs, and then for a while I was booting one of them into Windows (until I bought a couple Windows machines for gaming), and Windows only used the slow HD. A forced Steam game update could take half an hour. Also the various launchers sometimes have bugs and get stuck in a bad state, like at one point the Blizzard updater got stuck in "updating" mode and refused to start Warcraft III. Which should not need daily updates in 2022!
Don't get me started on the Blizzard installer/updater!
Must... not... rant... argh... okay fine:
It is the worst-written thing I have ever witnessed from a large software development company. The. Worst.
I once "took it apart" using reverse engineering tools, because one of the World of Warcraft expansions I was keen to play simply wouldn't install.
Why?
Because my CPUs were too fast.
It is an unbelievably complicated Rube Goldberg contraption of software that downloaded more software, which would it would run out of temp directories, which in turn downloaded more software that it would also then run as "services". At some point it had 4 processes communicating with each other using TCP[1], and this could very easily deadlock if you had a) 4 or more CPU cores, or b) if the CPU cores were too fast. Some of the processes could run in parallel across the additional cores, race ahead, try to communicate with something else that wasn't ready, time out, and crash.
If it failed for any reason, it would leave the executables and the config behind in an invalid state, from which it could never be recovered short of a low-level disk format.
At the time there were something like 10,000 complaints on the Blizzard forums, all being dutifully dismissed with "have you tried turning your computer on and off?"
I resorted to using a 1-CPU virtual machine on another, slower computer to install WoW, and then I would copy out the files to my gaming PC.
The hilarity was the the actual install process was just that: "copy".
No other steps were required. The entire installer was superfluous garbage written by a Too Smart developer.
[1] Among other things, this meant that you could never successfully use the installer if your Ethernet adapter wasn't the first in the list of IPv4 devices. You couldn't use the installer if you had VMware Workstation installed, a VPN, or a PPP dialup modem. (Or a firewall[2]) This was because... of course... the installer had pages and pages of code to "detect" your local IP address so that the processes could communicate with each other, instead of simply using 127.0.0.1 like a normal person.
[2] Of course a local firewall of most types would block the process-to-process traffic because it wasn't "localhost", it was going out to the adapter and back, which many products would process using different rules.
Must... not... rant... argh... okay fine:
It is the worst-written thing I have ever witnessed from a large software development company. The. Worst.
I once "took it apart" using reverse engineering tools, because one of the World of Warcraft expansions I was keen to play simply wouldn't install.
Why?
Because my CPUs were too fast.
It is an unbelievably complicated Rube Goldberg contraption of software that downloaded more software, which would it would run out of temp directories, which in turn downloaded more software that it would also then run as "services". At some point it had 4 processes communicating with each other using TCP[1], and this could very easily deadlock if you had a) 4 or more CPU cores, or b) if the CPU cores were too fast. Some of the processes could run in parallel across the additional cores, race ahead, try to communicate with something else that wasn't ready, time out, and crash.
If it failed for any reason, it would leave the executables and the config behind in an invalid state, from which it could never be recovered short of a low-level disk format.
At the time there were something like 10,000 complaints on the Blizzard forums, all being dutifully dismissed with "have you tried turning your computer on and off?"
I resorted to using a 1-CPU virtual machine on another, slower computer to install WoW, and then I would copy out the files to my gaming PC.
The hilarity was the the actual install process was just that: "copy".
No other steps were required. The entire installer was superfluous garbage written by a Too Smart developer.
[1] Among other things, this meant that you could never successfully use the installer if your Ethernet adapter wasn't the first in the list of IPv4 devices. You couldn't use the installer if you had VMware Workstation installed, a VPN, or a PPP dialup modem. (Or a firewall[2]) This was because... of course... the installer had pages and pages of code to "detect" your local IP address so that the processes could communicate with each other, instead of simply using 127.0.0.1 like a normal person.
[2] Of course a local firewall of most types would block the process-to-process traffic because it wasn't "localhost", it was going out to the adapter and back, which many products would process using different rules.
That is amazing. Have you written a blog post somewhere for this? Would love to share that around.
I had a much longer and detailed rant on Slashdot, but for the life of me I can't find the comment any more.
I'm really not painting a complete picture here. However bad you think it is from my description, I assure you that it was worse.
I'm really not painting a complete picture here. However bad you think it is from my description, I assure you that it was worse.
I hate Steam's auto-updating. Fortunately you can turn it off.
I think Switch games usually give you the option of starting without updating. And you can stay offline and just use physical game cartridges ... plug-and-play, like a classic Nintendo console. ;-)
Switch OS and game updates also seem ridiculously fast compared to some other consoles' updates.
Small quality of life features can add up to make a system much more pleasant to use.
I think Switch games usually give you the option of starting without updating. And you can stay offline and just use physical game cartridges ... plug-and-play, like a classic Nintendo console. ;-)
Switch OS and game updates also seem ridiculously fast compared to some other consoles' updates.
Small quality of life features can add up to make a system much more pleasant to use.
Only game updates; steam still fucking updates everyday or so....
I thought there was a Steam.cfg setting for disabling client updates?
And the changes are always imperceptible at the os level.
How mandatory could these things be?
How mandatory could these things be?
Signal.
Feel like it is every single day. It’s not quite that often, but it is very often. And I use it on multiple devices, so it really feels like every time I launch it.
Feel like it is every single day. It’s not quite that often, but it is very often. And I use it on multiple devices, so it really feels like every time I launch it.
This and surveys. Why should I answer a survey on quality every time I end a teams call?
I always give the worst possible rating I can give on these surveys. If somebody asks me why, I'm going to say, "Why? Because fuck you is why."
I wonder if this might lead to them attempting to survey you more often as they change minor variables during your calls in what they think are efforts to improve.
Yes, this is one of the drawbacks of the 'continuous release' religion.
This is largely driven by internal needs, not the needs of the customer the only benefit for which is some 'new feature' but which they pay the price for in terms of constant 'upgrades' and features jumping around everywhere, documentation completely out of date and other possible integration issues.
I think internal release cadence is fine, and 'constant upgrades' for certain subset of beta users, but major release should be just that, and, not required unless necessary.
The bureaucracy threshold has superseded the 'useful advances' threshold in most cases and so that should be contemplated by PMs.
This is largely driven by internal needs, not the needs of the customer the only benefit for which is some 'new feature' but which they pay the price for in terms of constant 'upgrades' and features jumping around everywhere, documentation completely out of date and other possible integration issues.
I think internal release cadence is fine, and 'constant upgrades' for certain subset of beta users, but major release should be just that, and, not required unless necessary.
The bureaucracy threshold has superseded the 'useful advances' threshold in most cases and so that should be contemplated by PMs.
This is where I think the OS "vendor" packaging application model (e.g. Linux distribution) is very nice. I periodically update everything, and don't really need to worry about each application.
There are a few exceptions (Discord sabotages it with mandatory updates, and I use Jetbrains-Toolbox's update mechanism) but for the most part it works out very well.
There are a few exceptions (Discord sabotages it with mandatory updates, and I use Jetbrains-Toolbox's update mechanism) but for the most part it works out very well.
I really like topgrade because it integrates all update tools in a single command https://github.com/r-darwish/topgrade
ok not all. It doesn't handle non-unix, proprietary updates. here's what it supports https://github.com/r-darwish/topgrade/wiki/Step-list
ok not all. It doesn't handle non-unix, proprietary updates. here's what it supports https://github.com/r-darwish/topgrade/wiki/Step-list
FileZilla. I've turned off automatic updates several times and it still does it. I've had probably 200 different FileZilla installers in my recycle bin. Putting aside whether I think it's unnecessary to receive so many updates for such tiny bugs/changes, it wouldn't be an issue if they just respected the fact I turned off updates.
You can go to ninite.com and download the installer for FileZilla. What’s cool about it is that you can keep double clicking the same installer file to update it.
From a business perspective it's because we do something called continuous delivery (the CD in CI/CD) where we choose to prioritize shipping regular updates. On most websites this is happening constantly behind the scenes, for apps we actually have to ship artifacts somewhere and get them to update. Some people choose to tell you when an update happens or give an option to decline it, others do it silently in the background.
There are a lot of reasons why, from operational (it's easier to develop quickly and get more revenue when you can ship updates daily/weekly to acquire new customers or reduce churn rather than postpone releases over long cycles and ask people to wait) to functional (if there's a security flaw that exposes you, my user, i want the software patched as soon as possible).
The big reason (to me) is an organizational one - it shortens the cycle time of code churn to QA to bug report to fix. When you stretch out release cycles that typically means you're doing feature/code investment up front, then bulk QA, then bulk bug fixes, then bulk QA (usually mixed with scope creep). With CD you just have tickets, they get moved to review/QA, the feature gets shipped, you pick up the next ticket. In a good workplace it's legitimately hard to have crunch time close to major deadlines because it's a lot less risky to delay a feature until a future release when that date is next week and guaranteed.
From a business perspective the advantage is that you can resource plan more effectively (you can forecast customer acquisition/churn much easier when there's constant feedback, therefore you can predict revenue cycles better, and you can also move people around a lot easier to hotspots with the highest priority). That's basically impossible with staggered releases because you're not getting input from the market on what you need to do to make more money and spend less.
There are obvious downsides, nagging aside. If it's easier to ship it's easier to ship broken things and half done things. And you can do things to make it more valuable to users like option updates to main and nightly/beta/security release channels. But those cost time and money to build and maintain and are kind of a nightmare for non tech-savvy users where using "nightly" to get the latest and greatest is a non-starter, and optional updates equal no updates and getting the same bug report in the queue for years. So some businesses don't do that.
It's such a big deal to me that when I interview I ask something like "when was your last release and when is your next one" to see if they actually have CD. As a dev you don't want to work in an environment where there's some long away deadline for release, that sucks.
There are a lot of reasons why, from operational (it's easier to develop quickly and get more revenue when you can ship updates daily/weekly to acquire new customers or reduce churn rather than postpone releases over long cycles and ask people to wait) to functional (if there's a security flaw that exposes you, my user, i want the software patched as soon as possible).
The big reason (to me) is an organizational one - it shortens the cycle time of code churn to QA to bug report to fix. When you stretch out release cycles that typically means you're doing feature/code investment up front, then bulk QA, then bulk bug fixes, then bulk QA (usually mixed with scope creep). With CD you just have tickets, they get moved to review/QA, the feature gets shipped, you pick up the next ticket. In a good workplace it's legitimately hard to have crunch time close to major deadlines because it's a lot less risky to delay a feature until a future release when that date is next week and guaranteed.
From a business perspective the advantage is that you can resource plan more effectively (you can forecast customer acquisition/churn much easier when there's constant feedback, therefore you can predict revenue cycles better, and you can also move people around a lot easier to hotspots with the highest priority). That's basically impossible with staggered releases because you're not getting input from the market on what you need to do to make more money and spend less.
There are obvious downsides, nagging aside. If it's easier to ship it's easier to ship broken things and half done things. And you can do things to make it more valuable to users like option updates to main and nightly/beta/security release channels. But those cost time and money to build and maintain and are kind of a nightmare for non tech-savvy users where using "nightly" to get the latest and greatest is a non-starter, and optional updates equal no updates and getting the same bug report in the queue for years. So some businesses don't do that.
It's such a big deal to me that when I interview I ask something like "when was your last release and when is your next one" to see if they actually have CD. As a dev you don't want to work in an environment where there's some long away deadline for release, that sucks.
That might be good for developer health, but its crappy for user experience.
And I've worked with some people that have literally wrote the book on CI/CD, so I fully understand the philosophy and benefits.
You probably need to at least throttle your auto-updates so that users who are just on autopilot don't upgrade more than once a month unless there's a truly critical update (not critical to you, but critical to your users). You can more or less stagger them and if they haven't updated in a month plus or minus some random fuzz that they pop open the auto update and download the latest changes.
That isn't CI/CD instant-feedback nirvana of every change, but you should dribble out enough changes to users in a few days to get enough feedback (this also limits the impact of any embarrassing critical regressions).
And most Enterprise users tend to deeply hate auto updates unless you happen to be selling only into other CI/CD using Enterprises. You want them all on the latest and greatest so you don't have to deal with bugs, but they want stable software until they decide to bump it. We tried imposing auto updates on Enterprise customers and they really hated it. You're probably going to have to find some kind of compromise there. Although I will also agree that having Enterprise customers that you have to support stuck on 5 year old versions of your product can easily kill the product.
But everyone has upgrade fatigue and you really need to listen to customers and find some kind of compromise.
And I've worked with some people that have literally wrote the book on CI/CD, so I fully understand the philosophy and benefits.
You probably need to at least throttle your auto-updates so that users who are just on autopilot don't upgrade more than once a month unless there's a truly critical update (not critical to you, but critical to your users). You can more or less stagger them and if they haven't updated in a month plus or minus some random fuzz that they pop open the auto update and download the latest changes.
That isn't CI/CD instant-feedback nirvana of every change, but you should dribble out enough changes to users in a few days to get enough feedback (this also limits the impact of any embarrassing critical regressions).
And most Enterprise users tend to deeply hate auto updates unless you happen to be selling only into other CI/CD using Enterprises. You want them all on the latest and greatest so you don't have to deal with bugs, but they want stable software until they decide to bump it. We tried imposing auto updates on Enterprise customers and they really hated it. You're probably going to have to find some kind of compromise there. Although I will also agree that having Enterprise customers that you have to support stuck on 5 year old versions of your product can easily kill the product.
But everyone has upgrade fatigue and you really need to listen to customers and find some kind of compromise.
What matters for the developer work experience is whether the product can be released frequently, not whether it actually is released frequently. Changes should only be merged to the release branch when they have passed all tests, so in principle you can take the contents of that branch and release at any time. But in practice you might release much less frequently in order to minimize customer impact.
That's a fair criticism but it neglects two realities I'm familiar with.
The first is that automated testing usually doesn't exist to the degree that you need it to be done. That's an engineering problem in and of itself, but manual QA still exists and always will.
The second is more important which is feedback from the marketplace. If you release infrequently you are harming the ability of the business to adapt and increasing the risk of what features people care about. This is something I see every single release cycle - more frequent repositioning is more stable and that's only possible with customer feedback. And as far as I know it can't be captured in automated testing.
The first is that automated testing usually doesn't exist to the degree that you need it to be done. That's an engineering problem in and of itself, but manual QA still exists and always will.
The second is more important which is feedback from the marketplace. If you release infrequently you are harming the ability of the business to adapt and increasing the risk of what features people care about. This is something I see every single release cycle - more frequent repositioning is more stable and that's only possible with customer feedback. And as far as I know it can't be captured in automated testing.
If you release too frequently you are harming the ability of the business to retain enterprise customers. They don't tolerate a lot of churn.
"As a dev you don't want to work in an environment where there's some long away deadline for release, that sucks."
And yet that's how devs managed for years and years before CD became even remotely feasible. And some projects are still run that way (I'm working on an open-source project that hasn't had a release in years and is still months away from it. It's a bit frustrating, but I can't see the situation being improved by pushing out a release before it's ready).
And yet that's how devs managed for years and years before CD became even remotely feasible. And some projects are still run that way (I'm working on an open-source project that hasn't had a release in years and is still months away from it. It's a bit frustrating, but I can't see the situation being improved by pushing out a release before it's ready).
Personally I don't defer to past practices as absolute wisdom. I've worked in waterfall environments and don't really want to go back. I like to be able to take vacations whenever I want and not stress about deadlines or go through crunch again.
The problem to solve is defining partial success as ok. If your product needs a whole set of discrete features to be releasable instead of an MVP set of discrete improvements and quality checks against regressions then something is off in the management and testing structure of the project.
The nightmare scenario I want to avoid is a user base that needs improvements and those improvements being done but releases blocked on things other users need. You don't want to delay things that can be valuable today once they work - that's bad for everyone.
The problem to solve is defining partial success as ok. If your product needs a whole set of discrete features to be releasable instead of an MVP set of discrete improvements and quality checks against regressions then something is off in the management and testing structure of the project.
The nightmare scenario I want to avoid is a user base that needs improvements and those improvements being done but releases blocked on things other users need. You don't want to delay things that can be valuable today once they work - that's bad for everyone.
TBH in this particular case the project manager would be the first to admit that the current release (which was a substantial rewrite of an already functionality-super-rich product) was way too big a piece of work to do in one go. But there was really nothing that could have reduced the time between the releases much below 6 months or so.
I certainly wouldn't call it a "waterfall environment" though! To be fair we are doing regular nightly builds that are accessible to the public, but they're very much pre-alpha and buyer-beware type builds that don't pretend to be suitable for most users.
Calibre [0] --great application but, as per parent post, every fecking time I open it there seems to be an update available. And it's never an in-place patch update or even auto-download either. Every time it involves having to visit the developer's site and downloading the entire ~300MB application disc image again.
[0] https://calibre-ebook.com/
[0] https://calibre-ebook.com/
I have always disabled the automatic updates of Android apps on my phone in Google Play.
I occasionaly go there and trigger the update manually.
Over the years, I've seen this operation to become more and more complicated to do. It's now hidden in the profile options. Shame on you Google!
Over the years, I've seen this operation to become more and more complicated to do. It's now hidden in the profile options. Shame on you Google!
Are you a very avid adopter of products from early stage startups? Forced updates tend to be more common with small companies that can't devote resources to maintaining backwards compatibility.
For apps that don’t need internet access to function I just block their network access. Or block their servers at the DNS level. They can’t force an update if they can’t phone home.
Even open source does this now. qBitTorrent is spamming about latest version available on every startup, and they do release often.
I assume that continuous integration and deployment have made their way to apps nowadays.
Filezilla is the worst for this.
That's because Filezilla uses updates as a vector for advertising... they're incentivized to make updates as small and trivial as possible.
Yes, it seems many adware apps do this. Do a small pointless update, show a splash screen listing the "changes", and cram an ad in there too (which is the real purpose of the popup). (Firefox is kinda the same, in that every time it updates, it shows you a new tab reminding you that you should pay them money for that pocket service...)