Back in the day, patches were used to cover holes in your jeans, not in commercial software. That's not to say software didn't include "undocumented features." But the severity of defects was nowhere near the level it is today, and we could afford to postpone fixes until the rollout of a subsequent software release.

Today, patches are not only commonplace, they're expected. And not just by customers, but by vendors. When Microsoft released Windows 2000, it did so knowing that the code stream contained thousands of defects. SP1 alone fixed more than 600 of these defects (see List of Bugs Fixed in Windows 2000 Service Pack 1.") Certainly some of them were minor, but it makes you wonder how many resulted in the rampant spread of Code Red, Nimda and other viruses.

Patch management today is a full-time job. You must keep track of all the patches available and micromanage them to ensure that the changes applied through installing a patch do not adversely affect production software. Companies need a mirror of their production environment simply as a test bed for the patch o' the week. Organizations need a tracking system to ensure they know which patch was installed when and on what machines. And the poor people managing it all need a vacation.

Getting to market on time is important for credibility, but not at the expense of security. Vendors need to take a more proactive approach to ensure that products aren't released before they're ready. While zero-defect software may be a myth (and as a developer I'll readily agree to that), it should be the goal. An organization should not have to hire staff dedicated solely to patching OSs and application software. And customers should not be unwitting beta testers. But it is routine for many software producers to treat first releases as beta products and ignore the needs of those who suffer from their shoddy Q&A practices and laissez-faire attitudes toward product quality. (For a review of patch-management tools, see "PatchLink Helps Keep Windows Closed.")