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!"
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.
Hogsback
One theory is that early market exposure is worth more for a product than fixing the bugs with a patch will cost. Every day a product stays out of the market, it's losing 100% of new sales on that day to the competition, and down the road when it's time to upgrade, people are much more likely to stick with a product they already know than to switch to another brand.
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.
I can't give you the whole picture or the one right answer (if such things exist) but I can share our policy.
The contracts are written and we have to reach a goal that resembles what was promised. Development occurs in the UK, and quite frankly up until now it was a messy project-driven group of products.
Imagine you have 3 customers, each with a heavily customised copy of Widget. Well, it's long i nthe tooth, and since you're a project-based shop, you only release a version 4.0 spec-- then code each different customer's Widget version to meet the new spec.
UGH.
Now imagine being in flux from this mess on your way to a product-driven development model.
Double-UGH.
So we want a customer-base and we promise them something we think we can deliver without losing too much on our contract penalties with. [Here's the meat of the post:] If not, we give them what we've got and release the patches afterward! Patches are also for bugs that crop up, but mostly, around here, they're tools to extend the life of our contract in the face of a development wild-space.
This may change in a few years, as this policy stinks, but by that time this will be, sadly, normal, and it'll stay that way.
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.
Basically, your question is why cant software be developed to perfection?
:P
Basic reason is that we always keep adding new features to it. It is impossible to stay on one set of features through product life. You simply have to add more and more and more... and you will never be able to test it properly. Not to perfection.
However, bigger issue lately is that companies are short on cash so they have to release software that is not ready to be released - software that has not been properly tested. Example I... World War II Online game - absolutly bad piece of software, kept crashing, etc... after several patches, its one of the best multiplayer games around... Example II. Mac OS X - first release did not have full support for all Mac hardware you could purchase (notably cdrw/dvd recorders)... they simly said we need to get it out and add this later
Most software that gets released actually deserves early beta status, which is why you dont see companies upgrading until at least 2 patches are released.
And even if you freeze your feature set, it cant last long... soon enough competition will have you scrambling to add more features and you wont have a year to properly test it... simply, I doubt there was ever a piece of software that was perfect and I doubt it will ever be... I for one cant wait for next patch for my router, OS, game or my favorite software