The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Upgrading software behind the user's back?


Reading coupled with recent discussions about the deployment problems of desktop applications versus web applications, I am left wondering why we bother prompting users at all.

What's wrong with upgrading software behind the user's back?

Caveat: Silent upgrades would not change anything outside the immediate boundary of the software. That is, you wouldn't change file associations or any other OS configuration that would naturally require user interaction.

What do you think?
Gili Send private email
Friday, July 11, 2008
Bad idea, imagine what if a bug slips in and their favorite feature no longer works. Now imagine how pissed the user is going to be when he finds out it was because of a magical upgrade feature.
Friday, July 11, 2008
Plenty of people have poked holes in the upgrade dialog before. Their line of reasoning went something like this... "If *you* don't know if I need to upgrade, how am *I* supposed to know?"

That is, whether I prompt the user to upgrade or not he is going to end up with some bugs along the way. The author is actually in a much better position to decide which version is stable than end-users.

Put another way: when my favorite feature is broken on a webapp upgrade why does no one complain? Why is this approach okay for webapps but not for desktop apps? :)

The reason I'm trying to convince myself it's okay is that I don't want to support backwards compatibility on my application. I want to upgrade all clients en-mass like webapps do. Please, keep on trying to poke holes! ;)
Gili Send private email
Friday, July 11, 2008
You don't own the user's computer or the data on it (including the application that the user is licensing from you). You MUST ask the user's permission before making changes to anything (including your application licensed to the user) on the user's computer. Doing ANYTHING else is just asking to have your ass sued off and will generate all kinds of bad will with your own customers (who will, in short order, stop being your customers, because you treated them like crap), even if they don't sue your ass off.

Why is this a difficult concept for so many people to grasp?

Would YOU use a program that made changes to itself without, at least, giving you a dialog saying that something was going on?
Jeffrey Dutky Send private email
Friday, July 11, 2008
Just asking......

What about Java Web Start type deployment tools?

Friday, July 11, 2008
"whether I prompt the user to upgrade or not he is going to end up with some bugs along the way."

But the user either hasn't experienced the previous bugs or has found workarounds for them. When they upgrade, they'll have to find new workarounds.

"when my favorite feature is broken on a webapp upgrade why does no one complain?"

Because only a small percentage of users actually complain. The rest either begrudgingly live with the problem or switch to a different vendor's application. If you want to know about problems, you have to take surveys.
Friday, July 11, 2008
Don't ever do it with software which is crucial for someone's profits.
quant dev Send private email
Friday, July 11, 2008
Very bad idea read this:

Quoting from that article:

"Until now, no matter how cynical the software manufacturer’s part of the annual upgrade dance, it took two to Tango, and those who didn’t want to upgrade anymore could just step off the dance floor. The ReplayTV incident is different: Users never requested a sharp reduction in the functionality of their machines, no notice was given that the machines would be downgraded in this way, and the users, who must of necessity tie to the TV logs to use the device, had no way of avoiding the damage that was done.

The reason this precedent is so important is twofold. First, computer software is likely to move to a subscription model, with software houses downloading changes as needed, in the background, rather than the once-per-year model we’ve previously had. User may awake one morning to discover an ad appearing in the middle of their Save dialog (“If you really want to Save, why not shop at Thorny’s Discount Bait Shop?”) with no means to revert.

Second, upgradability is finding its way into other traditional products. Several stereo preamps and receiver manufacturers are trying to keep up with the explosion of multi-channel decoders by making them software upgradable. As home automation becomes more commonplace, everything from refrigerators to telephones may need periodic upgrades, particularly since, because of the “as-is” phenomenon, the first release will almost always be defective.

Unless people are protected from purposeful and involuntary downgrades in the usability of already-purchased products, we will see a deterioration of consumer rights unimagined before. “Buyer Beware!” is one thing, but how can you beware of what the manufacturer will do to damage or degrade your product years after you bought and paid for it?"
Friday, July 11, 2008
If you do that, you better have a very intense QA process in place. It's a surefire way to severely piss off your users if you introduce any regressions with an update that they did not ask for.

It's so easy for regressions to happen that it just makes this a generally bad idea.
Michael G
Friday, July 11, 2008

A user inviting a regression bug (even unknowingly) is not nearly as bad as forcing a bug on them. 

When someone contacts you with a bug in an old version, tell them they can get the latest release for free.  That almost always gets them to upgrade to your supported release, especially if you've already fixed their bug in the newer version.
Friday, July 11, 2008
There is a golden rule in software that you may not have heard yet.

If it ain't broke, don't fix it.

I resisted switching to firefox for years, because it had this auto upgrade feature.  I switched only after I learned that this feature can be switched off.
Sunday, July 13, 2008
Well, apparently everyone disagrees with me :(

So I'll ask this another way... Given the fact that I don't want my server to have to support outdated clients (purely because I'm a one-man-shop and don't want to spread myself thin) what is the best way to handle this?

I could prompt users for a mandatory upgrade and if they refuse I deny them access to the server... but that seems even worse to me than silent upgrades. What do you suggest?
Gili Send private email
Sunday, July 13, 2008
Forced auto-upgrades may disqualify your software from companies that have strict rules about this sort of thing.

>I'm a one-man-shop and don't want to spread myself thin

That's *your* problem, not the customer's.  When you become huge you can kick "legacy" customers to the curb.  Until then I'd suggest taking whatever steps necessary to not alienate those who believe in you at the beginning.
Anonymous Hippopotamus
Monday, July 14, 2008
If you're a one-man shop, then supporting only one version seems reasonable to me. "Thanks for your bug report, but the current version of WidgetWare is 2.2. Can you try upgrading and see if the problem persists?"

The catch is, the above is perfectly reasonable so long as it's free for that user to upgrade to 2.2. If they're using 1.1, it's not very nice to say that they're SOL unless they pay to upgrade. But if you were to, say, provide support for only the final version of each major release, and provide free upgrades between majors, then saying "Sorry, you're using 1.1. Please either upgrade to 1.85final, or feel free to upgrade to 2.2 for the low low price of blah" is still perfectly reasonable.

But upgrading them behind their back? Absolutely not. Even if there's no possible reason for the user to decline, at the VERY least let them control the timing. I don't want some app to go haywire because I undocked my PC while it was updating or whatnot. Or perhaps I happen to notice that the app's CPU usage jumped up, so I force-quit it while the updater was running. No sense in inviting that kind of problem.
aph Send private email
Monday, July 14, 2008
>I could prompt users for a mandatory upgrade and if they refuse I deny them access to the server...

In large corporations, most of the users are locked down and can't upgrade even if they wanted to. All pushes have to come from corporate, pushed down the wire with SMS or Tivoli (or some other equivalent stuff). 

That said, we do provide updates and patches during the year. Unfortunately, the patches for some products are in the 100-200Mb range. I'm currently making an app updater that will work under Vista with limited user accounts (where ClickOnce cannot work). And to deal with folks undocking or turning off the box, I'm using BITS and allowing the user to schedule the checking (once per night, manually, never or whatever the user wants). It won't run when the app is, it won't stop the app from running (we are not certain that all of our customers have internet access and we do know that some of our customers have dial-up). The major hassle that I can see is that we need more discipline at the server end than we currently have. The other major hassle that I see is that we should clearly mention what bugs get fixed and how they impact the users. 

For customers with SoX/GLBA compliance concerns, I can see making it clear how to install/upgrade our apps to disable the app updater.
Peter Send private email
Monday, July 14, 2008
1) My application is free so users should have no problems upgrading.

2) I don't see why undocking is an issue. You could download any patches in the background and only apply them the next time the program is launched (like FireFox). If undocking occurs you simply restart/resume the download.

I get the feeling from dd's posts that he got burned by major releases (say FireFox 2.0 or 3.0) and he'd rather wait until maintenance release 2.1 or 3.1 comes out before allowing an upgrade. I do the same thing for Subversion sometimes.
Gili Send private email
Monday, July 14, 2008

You clearly want to do this, since you're just taking everybody's valid objections and dismissing them.

So just go ahead and do it, and let us know how it went.

We on the JoS forums love Cautionary Tales.
Monday, July 14, 2008
If I found your software doing this, I'd remove every installation of everything from your company from every computer I control.

Sure, *you're* only updating the program you wrote, but what about <X>?  Which of you do I blame when something goes south?  Which of you will pay what it costs me to unfsck my systems?

For me, better safe than sorry - I won't use your stuff at all.
ain't tellin' Send private email
Monday, July 14, 2008
I think the answers you will get from a programmers forum will always be skewed.  Programmers are people that want CONTROL of their computers, first and foremost.  They want to control everything that happens, so they hate this idea of doing things automatically, or doing something that they weren't aware it was doing.

Consumer computer users are generally much less interested in control, and just want it to work, so they can do useful things.  They have no urge to tweak settings or explore options beyond what comes out of the box.  They will happily take anything from you as long as it continues to work, and does things they want to do.

I think you are safe to do this, as long as you give the control people an option to do the controlling, and make it clear you will be doing this.  If it looks like you are hiding it, people will jump all over you.

You will also need to be careful to not radically change things.  If your changes are small and gradual, most people won't care and will be happy about the incremental improvements they see.  If an update suddenly rearranges the entire design of the app, you'll probably annoy a large numbers of people.

I personally like how firefox does it.  It tells me there's a new version downloaded and ready to install, and I have the option to say "not yet, I'm doing something".  After the install, it comes up right where I left it.  Fantastic.

Apps like shockwave drive me nuts, constantly telling me there's a new version, do you want to get it?  You know what, I don't care.  If it just went and installed it, I probably wouldn't even notice, so why does it keep annoying me.  Shockwave isn't even an application with an interface anyway.  I never care what version I have, as long as the websites that use it work.

Monday, July 14, 2008
I can see how there are some possible legal ramifications in updating people's computers without their express consent but personally I think its desirable to silently autoupdate.  just get permission during the installer maybe.

We have autoupdate turned off on production servers so we can batch updates at known times but for personal machines go ahead and apply your patches.  Dont bother me with it.

My pet hate is apps, virus scanners in particular, that pop up every few days telling me I need to click on update then telling me that they successfully updated a minute later.  Why do I need to know?  Me being involved is adding nothing to the process.  If Im using the computer its to accomplish some other task and not to spend time updating software.  Just silently go get the patches and silently apply them without interrupting me.

If the product's own developers thinks its a good idea to upgrade Im not going to disagree.  While theres certainly the potential for new bugs there are almost always more old bugs fixed then there are new bugs introduced.

The only exception in my mind is moving to a new .0 release. 2.0, 3.0 etc.  Major version upgrades should be autoapplied as I might want to wait for the .1
Andrew Send private email
Tuesday, July 15, 2008
Recently my internet connection stopped working. I had let Microsoft Update run the previous night, so a bit of research showed that ZoneAlarm and Microsoft's latest security patch didn't work together. Uninstalling the patch restored connectivity.

Now if Microsoft auto-installed patches without prompting, how could I determine that? I would likely reformat the system, wasting time needlessly.
A reader
Wednesday, July 16, 2008
Gili: "1) My application is free so users should have no problems upgrading."

The above statement is true enough, and so is:
"1) My application costs [cue Dr. Evil] one hundred billion dollars so users should have no problems upgrading."

Your app users should also have no problems NOT upgrading.

My editor of choice is WordStar.  I bought my copy in 1988.  It works for me like none other.  I dropped AVG AV in evaluation because it kept flagging it as a virus and gave me no option to override this.

If you try to drag users kicking and screaming, expect a few head shots and diminished hearing.


Gene Wirchenko
Gene Wirchenko Send private email
Wednesday, July 16, 2008
You're ignoring an overriding principle: people want to be in control of their computer. To quote Joel: "To make people happy, you have to let them feel like they are in control of their environment."

If you auto upgrade, you're going to make some of your users unhappy - perhaps unhappy enough to stop using your product altogether.  You can see that in some of the responses on this thread.

How do web apps get away with it?  Some of it might be the perception of a different environment; once you're on the web, you're leaving your own space and entering someone elses.  More likely though, people don't have a choice so they just learn to live with the annoyance.
Mark Ransom Send private email
Wednesday, July 16, 2008
You should not update your software behind the user's back, because the software would end up in the users chair.

It is better to have the software upgraded in front of the user that it is where their computers are.

good luck.
not a guru Send private email
Monday, July 21, 2008
Your question has different answers depending on who the end-users are, so ultimately you are going to have to test it for yourself rather than rely on what you hear on this forum.

Having said that, here are your options as far as I can tell:

You can either make it opt-out, such that autoupdate is the automatic behavior. However, the first time it runs, it should tell the user that it is about to autoupdate (as if it was opt-in) and do get his consent that this is ok to do so in the future without further permission requests (you will still need his permission for running under Vista though). If he is a control freak, let him opt-out. It is also nice to update before the next time the application runs rather than interrupt what he is doing right away unless you can restore everything back the way they were EXACTLY.

Or make it opt-in and have a separate option "to check for updates". Once a new update is found, notify the user. If the user wants nothing to do with updates, allow him to opt-out of checking for updates too. If the user decides to just let the app handle the updates automatically, give him the option to enable autoupdates here as well.

This way everyone knows everything and everyone can have it their way.
Wednesday, July 23, 2008
"My editor of choice is WordStar.  I bought my copy in 1988.  It works for me like none other.  "

Wow, really?  I haven't heard that name in 10 years.

Gili, How about putting in the effort to make your client and server both forward and backward compatible, instead of autoupdates?
Thursday, July 24, 2008

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz