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?
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.
This sometimes even lets me present the same win for two sprints.
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.
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 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.
How mandatory could these things be?
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.
The update experience is lacklustre. It's a large, bright, call-to-action asking me to 'Click to restart Signal'. For me, the app always functions normally if I don't update, so why the immediacy of the message.
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.
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.
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
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.
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.
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.
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).
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.
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!