Jul 27 2007
Designing Software Patching Systems
Think about the software you have on your computer right now. You probably have several dozen programs that provide a wide array of functions. And you probably are missing at least a few software updates, and likely several security related updates.
While most software patching systems are badly designed, there are a few notable exceptions like Microsoft Windows and Firefox. Still, the trend of automatic patch integration is only just appearing in software. But the trend will continue: by 2015 most software will include automatic patching systems.
Unfortunately, almost all patching systems are badly designed for one simple and shared characteristic: the burden of patching is placed on the user. The user must decide at an arbitrary time to go and seek out a patch. The burden must be placed on the software and the process must be automated.
A few guidelines for any update system:
- The system should discretely check at regular intervals for new patches;
- If the software package has a client and server components, then patched servers must always be backwards compatible with clients;
- The update process must be automatic, seamless and discrete from the perspective of the user (Firefox does this the best); and,
- The patches must always work.
Guidelines 1, 2 and 3 aren’t really that hard to implement (the only hard part is actually making the effort). Guideline 4 probably scares a good deal of programmers. As it should.
It’s a big goal to strive for: patches always working. And you won’t always achieve it. But if you strive any lower, you will have too many problems too frequently, and you are guaranteed to lose customers. With a disciplined testing regime in place that is consistently repeated, the experience will be mostly harmless.