Comment Re:Full waranties are quite reasonable (Score 1) 393
Given the software development technologies and practices that we have today, are software warrantees currently practical?
I contend that they are not.
Physical manufacturing has been playing their game for hundreds of years. We've been "manufacturing" software for just 40 years. Manufacturing and manufactured products are constrained by physical laws. Software, and software systems, are free of this limitation. Most physical products have fewer parts than significant software systems and are much easier to test. All in all, it's easier to raise the quality of a physical product than it is to raise the quality of software. And "easier" equates to "cheaper."
The other example you cited, GTech, is a vertical application with very specific requirements for success and performance. They also have a direct monetary motivation to improve the quality of their software (i.e., fewer errors == lower penalties). Any resources they commit to improving their software translates directly to an improved bottom line.
I would guess that if your were to examine the software they use to achieve their 0.3% penalty rate, you would likely find that the software itself is less complex than, say, M$ Word. It probably has fewer KLOC, has no GUI, doesn't have to contend with backward compatibility and probably supports no interoperability with other software. Plus, GTech has probably committed many, many thousands of hours to writing, testing and debugging this one application.
M$ could do the same thing for M$ Office. But who wants to pay $5,000 for M$ Office?
Also, regarding the "AS-IS" warning: nearly every EULA that I've actually taken the time to read is nothing more than an AS-IS warning wrapped in Lawyer-Speak. This is the problem. Most (all?) software today is delivered "as is," without guarantees and without hope for a consumer to seek retribution for any damages that arise from using the software.
To offer a warrantee, the warrantor (is that a word?
Now, of course, no software company wants to be sued. So, to keep from being sued, they'll have to raise the quality of the software they deliver. This process is not free; it's certainly not cheap.
Improving software quality requires more front-end work (analysis, design, etc.), improved development techniques and tools, and stronger verification techniques (automated testing, monitoring and improving path coverage, etc.) This all costs money. Since most companies are in the game for profit, if all these costs were embeded in the development process, the only way to maintain margins would be to raise the price of the delivered software.
There is another possibility, too: don't improve the software, expect to be sued and expect to pay damages. Now, to maintain the bottom line, send the attorneys, accountants and statisticians into a room, crank some numbers and come up with a new price structure for the product line that will maintain the current profit margins, and still pay for the anticipated damages.
I argued elsewhere in this thread (Liability Laws Impossible for Software (today)) that, while software warrantees are surely desireable, using current technology, I question whether they are practical.
To me, at least, the problem is not that we should offer software warrantees. I think everyone agrees warrantees are desireable. From where I sit, the problem is that current technologies and practices make providing software warrantees prohibitively expensive and therefore make them a practical impossibility. At least today.
Until we as an industry can make "better" software at lower cost, the whole discussion of software warrantees is, again, in practical terms, moot.
Finally, this argument only applies to consumer and business software. Man-rated systems (avionics, etc.) have no room for error and we should spend every penny needed to keep from inadvertently killing someone. However, while using M$ Word, most people's lives are not at risk. Their jobs, maybe, not not their lives.
Just my $.02.