Slashdot Mirror


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!"

3 of 39 comments (clear)

  1. Why? by hogsback · · Score: 3, Insightful

    Why send out 'broken software'?

    Usually because you don't know it is broken at the time. The real world is a much harsher test environment than internal or even beta testing.

  2. Just part of software. by Xenopax · · Score: 3, Insightful

    To answer your question on if patches are finacially motivated: yes and no. Yes as in you have to release a product eventually, but no because you will never write a perfect software program the first time around. There are so many things that can effect your software from hardware, drivers, other software, etc. You can not possibly test every single configuration out there, so at some point you have to rely on feedback from your customer to find problem areas.

    That being said, there are times when products are rushed out the door before they are ready. I had experience with that at my old company, and the reasoning was purely finacial. I really can't fault them for releasing early though since we had to play a delicate balance of releasing something good and going under, and eventually had to split the middle.

  3. Re:They Write The Right Stuff by gorillasoft · · Score: 3, Insightful

    From the article: ... the groups $35 million per year budget is a trivial slice of the NASA pie, but on a dollars-per-line basis, it makes the group among the nation's most expensive software organizations.

    I don't think following their method is a viable commercial model. You would virtually always be beaten to the market, and you would have such large up-front costs that you may not be able to survive until the software is released and selling well. NASA has the benefits of massive funding and defined problems that they can wait to solve correctly rather than worrying about selling a product just to survive. Oh, and if they don't do it right, somebody may be killed. That's a large incentive to spend the time and dollars necessary for nearly flawless software, but it doesn't translate to most corporations' markets - thus the release of buggy software that requires later patching.