 | Level: Introductory Peter Seebach (crankyuser@seebs.plethora.net), Writer, Freelance
01 Nov 2006 No matter how pretty the box is, most software will someday require a patch, probably even quite a few. This month Peter offers tips for writing and releasing patches that your users will appreciate...or at least not absolutely despise.
The purpose of a patch is to fix a specific problem with software.
For example, the software might be missing a feature that has become
indispensable since the software was first released. While you can just release a whole new version of the software, patches are often much
smaller than an entire software release, allowing users to quickly
download them and update their software.
Patches are primarily aimed at correcting bugs, such as security
holes or reliability problems. If a bug creates security
vulnerabilities, it may be important to get a patch out very quickly;
for instance, when the famous Pentium "f00f" bug was discovered, UNIX
vendors scrambled to release patches for their kernels. (It was possible
to work around the bug in software, so Intel didn't need to release a
fix.)
Whatever the reason for a patch, developers should be sure to
provide information about its functionality to users. Ideally, users
should be able to see both an overview of the patch and an exhaustive
list of every change it will render to the software. The phrase "Minor bug fixes"
is in no way sufficient information for users trying to decide whether
to load a patch. A user who has trouble with a program needs to
know whether a patch solves that problem, or adds new features, or
what.
Patch requirements
The more requirements imposed on the installation of a patch, the
harder it is for users to apply it. On the other hand, it's a good
idea for patches to check for prerequisites before running. A patch
that fails to do so might easily break the software it's supposed to
fix.
Some patches require access to the original install media to run
(this is popular with office software, for some reason). While
obnoxious, having the media on hand can enable a patch to be both
smaller and more reliable, since you have some reasonable control over
the contents of the original media. One application I loaded recently
offered an optional extra 270MB component which would let you apply
future patches without the original media handy.
While some dependencies are unavoidable when you write patches, you
should limit them. In the worst case scenario, too many dependencies and
requirements will render a patch pointless. For example, I once needed
to upgrade the BIOS of a motherboard. The vendor provided upgrades only
in one format -- a DOS program that wrote directly to the floppy
controller. You could not extract the image to a file or to a USB
floppy; you had to have an old-style floppy controller. You could not
extract this image unless you had access to a DOS prompt (in fact, I
don't think it even worked under recent Windows releases, because it
needed direct access to hardware now controlled by the OS). After much
trial and error, I managed to run it using VirtualPC on a Mac to create
a disk image, which I then used to create a bootable CD. It was a lot
of work, and furthermore, the patch executable was substantially larger
than the actual files it needed. The intent was to produce a reliable
and simple way of making the necessary floppy; the practice was to make
something that didn't fit well with the rackmount server product it was
for.
Another thing to be wary of is requiring users to re-enter lots of
registration information, such as 25-digit keys. Users lose this type
of information all the time! If your patch prevents a user from running
a crucial program for the days or weeks it takes to track down that
data, you will probably lose that customer.
And finally, don't make a big production of trying to prevent the use of your
patches by unauthorized users. This is especially true
for security patches. The harm done to users of compromised machines is
simply too great. And besides, I've never heard of anyone with
unauthorized copies of software being inconvenienced by the security
constraints on a patch, but I've been bitten by it many times on
software I really did purchase.
On compatibility
A patch should not break compatibility with existing data files. It's
just that simple. Breaches of compatibility do happen sometimes; more
often with video games, less often with productivity software, but the
number of times I've discovered that I need to redo all sorts of work
because of a minor update is far too high. If you think about
changing your data format, take advantage of the clearly
defined header in your data files, which indicates the version of the
data file. Your patch should be able to read in the old data. If you
haven't put in some way to identify file versions, shame on you! This is
not a new idea. It's been around forever, and it really does work.
Also, patches should not break functions that previously
worked. Sometimes it's unavoidable -- for example, security patches
tend to intentionally constrain some operations. Nonetheless, try to
keep it under control. The process you need to keep in mind when
you write patches is regression testing. It's a technique that tests the original program's functionality to make sure it still works even
after a patch. Often, you can isolate specific components of a system known to have had problems in the past and develop exhaustive tests to apply after any update to ensure that it doesn't
break anything. Do all that before you ship a patch and you'll see much
better results.
All rolled up in
one
When I got a brand new laptop a couple of years ago, the
system-provided update checker found, as I recall, 16 critical patches
that had to be installed immediately. The problem was, it couldn't do
them all at once; one of them had to be installed separately from the
others. So I did the procedure: installed that one first, rebooted,
then installed the other fifteen, then rebooted. As you might guess,
when I checked again, there were more patches to install. I think the
whole process took something like five reboots.
A year or so later, I had to reload the whole system, and it took
even more time and more reboots. Every so often I'd stumble across a
critical patch that had to be installed before the other critical
patches that followed it could be installed. More recently, I installed
a system and found that, from the very most recent CD distributed by a
particular software vendor, there were 59 critical updates.
That is, as it happens, rather a lot of updates, reboots, and time
spent.
One way to get around this sort of user frustration is to release all
patches in a bundle. Sure, there's something to be said for releasing
patches quickly when relevant issues come out; you'll always need to do
that. But some patches, such as more feature-driven ones, or
non-critical fixes, can be bundled and shipped with a universal
installer. Release this bundle as a single download that updates the
user's system to a new version number (as Apple does with its Mac OS X
releases) and you'll win users over without even trying. (I don't
always like Mac OS X, but I cannot fault Apple's handling of
updates. A recent fresh install required me to download a total of four
files that incorporated something like a years' worth of patches in one
big bundle and added a couple of minor ones. I only had to reboot
once.)
Bundling isn't just a question of user convenience. If you have
multiple separate patches available, you have to do QA testing and
debugging on every possible combination. The amount of work involved
goes up exponentially with the number of patches, unless you just blow
it off and leave it up to the old "we think it'll work" principle.
(Please don't do this!) Rolling patches up into a jumbo edition helps,
but simplicity isn't the only benefit. Another benefit is that the
version number of the product as a whole can be modified. It's easy to
ask a user whether the Mac is running "10.4.6" or "10.4.8". It's not so
easy to ask a user whether a Windows machine has a relevant patch
applied. Linux systems tend towards a potluck approach, but generally
individual package versions can be checked.
Old versions
Whenever possible, keep patches available even for older versions of
your software, or software you no longer support. Someone out there
is going to want the DOS extended memory manager your company
stopped selling in 1999 to work on an emulated PC, and is going to need
the patches that were released shortly before the product was
discontinued. The cost of keeping up old patches shouldn't be that
high; after all, traffic is low. If you don't want to deal with it,
give them out along with a clear statement disclaiming warranty and
permission for other people to copy them. Intermediate patches,
updates, whatever -- put them out there in case someone needs it. When
I'm looking at new software, the availability of updates for old
software from the same company is a big factor in my evaluation. Why
should I give you my money now if you're going to abandon me in a couple
of years?
Automated patch download and installation procedures are nice, but
you should make sure that users have an easy way to just download the
patch so they can keep a copy. I have games I can never play again
because the vendor went bankrupt. The program for updating my beloved
games can no longer find the server it's supposed to connect to, which
just bites.
In conclusion
Patching is inevitable: there will be bugs and they will need to be
fixed. And remember:
- When you release a patch, make clear what it fixes, and be sure
it fixes that thing consistently.
- If you release a number of patches, put out bundled releases fairly often that provide an "everything up to here, no matter what you had before" solution. I should not have to download 59 patches to get current on a single software product.
- Make older patches available, even long after you're no longer making
new ones for that product.
All this may sound complicated. If you would rather simply release
software that is completely bug-free on the day it ships, and never
develops a bug, I'm okay with that, too.
This week's action item: Run every software update tool,
check for updates menu item, and so on, that you can find on your
computer. Try different patch processes. How many times do you have to
reboot to complete the whole series?
Resources Learn
Get products and technologies
- IBM trial software: Build your next development project with software available for download directly from developerWorks.
Discuss
About the author | 
| | Peter Seebach has been using computers for years and is gradually becoming acclimated. He still doesn't know why mice need to be cleaned so often, though. |
Rate this page
| |
