Designing a Software Patching System
Consumer’s expectations in general always increase over time. This is inevitable given the relentless march of progress and is no different for software. Any modern software system that is worth its salt these days, has to support a whole host of features. One of these must-have features is patching.
Patching, sometimes also called as automatic updates comes in many different guises in the software world. These start from ubiquitous software updates in OS’es like XP, Vista, Ubuntu to other common place software like Anti-Virus, Firewalls, Office suites and so on. Designed well, these updates help the user keep abreast with changes, reduce technical support, keep the system secure and so on. Designed badly, they turn into a nagging system that constantly chastises you for playing hooky and not upgrading. It forces the people who know how, to turn on options like ‘never check for updates’ thereby defeating the whole purpose of auto-update systems.And it forces the people who don’t know how to always click on these pesky message box reminders EVERY SINGLE TIME they interact with the software. This doesn’t win any enthusiastic supporters does it?
So if we are trying to create a software patching system, how and where do we start? Here’s a set of requirements:
- Easy-to-use, minimal user intervention when automatic updates are enabled
- New version notifications should be in the background
- Works (or fails gracefully) in non-admin mode
- Supports incremental patching
- Easy to administer and manage software patches
So, let’s start going through these requirements in detail:
The software patching system has to be essentially invisible to the end user. Especially, if automatic updates is enabled, every time the system is updated, there should be little or no effect to the end user. This makes for an overall good experience. A good example of this kind of turn-it-on-and-forget-it kind of patching system in use is in Firefox. I haven’t had a time that the firefox update failed or I had to do some additional work. It automatically detects that it has updates and next time I restart firefox it applies it and restarts itself. This is what I would call unobtrusive.
New Version Notifications should be in the background
This requirement doesn’t sound like a big deal, but *many* programs do this and make the decision for you that everytime you open the program you are interested in mainly knowing about the latest update. Most times it is not. The user is in the program to do some work. They would care less if they were running 18.104.22.168 vs 22.214.171.124 as long as they are able to get their work done. Some programs are slighly better in this regard, allowing you to change the behaviour of the notification to be less obnoxious, but the default is set to be obnoxious. See example below:
On the other hand, see WordPress’s update notification, not obnoxious, but still useful.
Now, I can see a few people objecting to this saying that if the system requires a high critical update, this update notification should be shown to the user first thing, come what may. Yes, I agree, you need to show this to the user, but not push it down their throat, for example showing this via a Modal dialog still is bad. Just because you pushed this down the user’s throat doesn’t mean that the user wants to update the application right at that time. If there are security implications, it is still his decision to take that risk.And the software application has to respect that, irrespective of whether it doesn’t match it’s objectives.
Works (or fails gracefully) in non-admin mode
In the Windows world, most users have been conditioned and accustomed to running as an Administrator. This is mainly because most software (including mine) have assumptions about several things including, write privileges to the Program Files directory. Normally, writing to the Program Files directory is only possible when a program is running as administrator.
When an update program runs it has to consider the fact that the user could be running with limited privileges and either detect and handle this error gracefully or work around it.Either way, the update should either succeed or fail. If it failed, the user should know precisely why. Most times, software that fails this way reports a cryptic error message that no-one except the developer can figure out.
Supports Incremental Patching
This is somewhat related to the ease-of-use thing. Most patching systems, neatly sidestep the whole update issue, by downloading a brand new installer and starting it when you click on “Update Now”. One of the reasons this is bad, is inefficient use of bandwidth. Most applications when they are being updated just change a few main files. Very rarely do all the files require changes. So downloading a full application installer is inefficient not only for the user’s bandwidth, but also to the the server that is hosting these changes.
The other reason, having the full installer downloaded is the confusion created. Most times it is not clear whether the software should be uninstalled first before starting the installer or whether the installer will take care of this for you. I cannot count the number of times that after the installer churns away for a few minutes will abort the install saying that the previous version needs to be uninstalled first. Aargh. The other reason this doesn’t make much sense, is because this approach won’t work for software installed for example on USB keys.
The best patching systems allow incremental patching, i.e. downloading only files that have changed and applying them. This reduces bandwidth, removes confusion on installers and works on portable sofware.
Needless to say, security while dealing with patching systems is imperetive. For example, the software should not be misled to download software updates from an attacker and install them on the user’s machine. This is especially important in these days where even DNS poisoning attacks can fake the location of the webserver.
Easy to administer and manage
This requirement is not from the user’s side, but purely focused on the developer and operations. Creating a patching system satisfying these conditions is not too hard, but creating one that is easy to manage and maintain is actually more tricky. Over the lifetime of a product, hundreds of patches will need to be created and maintained and quickly this becomes a full time job for the unlucky person. For example, RTPatch, an incremental binary patcher can create differential patches given two binary files. But then if you have N versions of your product, every new version will require patches from all previous versions to move to this latest version. This becomes unmanageable.
The correctly designed patching system alleviates this problem.