History of Software Patches?

NinaBeth asks: "I'm interested in the history behind software patches for an academic paper I'm writing. In particularly, I'm wondering what motivates shrink-wrap software companies to release patches? Why send out 'broken software'? Is it purely financial? Has anyone done a cost-savings analysis of QC prior to release versus user-reported problems? Any stats on the average number of patches an application will require? Is any one particular company more patch-happy than others? I don't need much, just a reference or two would be helpful. Thanks for any suggestions!"

Comments

Software Patches

[Slipped_Disk]

Well I can't say it authoritatively, but patches have probably been out since the very beginnings of programming - at the very least since the beginning of UNIX.
When you think about it, all the Unices, commercial or free, have always released patches. In Linux and the open-source BSDs these are released as source code (diffs or checked out of CVS), in the commercial world binary patches that either replace or edit a portion of the files on your computer are often released to address security or functionality problems. I honestly can't think of any other major piece of software (OS, app suite, windowing system) that hasn't released at least one "apply this today or your computer may explode" patch.

As for the "why" of releasing broken software, I can personally attest to the fact that most companies probably DON'T know about the problems until they come up in the real world. When my company tests software we try to think up extreme or improbable cases along with the mundane, but invariably we miss something.
IMHO the releasing of buggy software isn't necessarially bad - but on the other hand if you KNOW a bug exists and it is fesable to resolve before a release, that should be the prefered solution (as opposed to a patch later).

As for the average number of patches a piece of code requires, the codebase for the larges application I am currently working on has had well over 100 internal patches (things which didn't cause functionality problems but still should have been fixed). These fixes were sent to customers in 10 seperate external patches (a patch that increments the z in x.y.z versioning) which also fixed functionality problems that we discovered in additional testing or that the users reported.

For larger-scale examples, check out the lists of patches for solaris (www.sun.com) and MS Windows (windowsupdate.microsoft.com - assuming it's back up)

Hope this helped a little.

Deadlines, quotas, metrics, and some history

[imrdkl]

First, if you are really interested in the history of patching software, then check out the patch(1) program for applying source level patches. This was written originally by Larry Wall, also the author of perl, and a well-known cofounder of the internet (so to speak).

If you dropped Larry a line, I'd bet he'd be willing give you some perspective, at least from the Free Software point of view. He used to release patches directly on USENET, now that was a great way to keep customers happy...

The rest of your question can probably be answered by the first three words in the subject of my comment. If it builds and runs on the announced shipping date, and there are no (or very few) show-stopper bugs, then most companies will cut CDROMS and ship.

Re:Why?

[larien]

The real world is a much harsher test environment than internal or even beta testing.

As per the The Ten Commandments for C Programmers says:

...for surely where thou typest "foo" someone someday shall type "supercalifragilisticexpialidocious"

It's amazing how silly/malicious some (l)users can be.

There's also the maxim that companies keep writing more foolproof software, but the world keeps building better fools.