Slashdot Mirror
Calling Software Reliability Into Question
phillymjs writes "CNN is running a story on software reliability, and how the lack of it may cost more and more lives as technology creeps further into everyday products. It appears a debate is finally starting amongst everyday (read: non-geek) people about vendor liability for buggy software. Some opponents of the liability push are unsurprising: Says the story, 'Microsoft contends that setting [reliability] standards could stifle innovation, and the cost of litigation and damages could mean more expensive software.' The article also says, however, that consumers' favortism of flashy products over reliable ones is partly to blame for the current state of software."
...could reliability standards stifle innovation? How hard is it to design something that works well and is extremely robust, yet, be creative and innovative in its design?
The trouble is, the more accustomed users become to bugs, the harder it is to get them reported and fixed. If my computer crashes, I just reset it and get back to work. I don't bother to investigate what caused the bug, to try to reproduce it, to contact the vendor (hah!) and try to work out the problem. Crashes occur much too frequently for that.
OTOH, if computers were reliable enough to crash only once every few years, then users might report every crash that happens, the vendor can diagnose it, and fix the bug or family-of-bugs so that it never happens again. This is roughly what happens when a mainframe crashes, I believe - it's a big event.
Imagine if when your microwave crashed, you could call some hotline, they would come and replace the microwave and take away the old one for analysis. Instead, even on complex software systems the standard first resort for the help line is 'reboot and see if it goes away'.
-- Ed Avis ed@membled.com
The company with the most to gain from this (with its unique cash reserve - Microsoft) is the company most in opposition...
Yes, I said it. I'll say it again. Microsoft could gain *alot* from this movement.
With their resources, they are the ones that could easily afford a true source-code audit the likes of which the BSDs are only beginning to approach.
They could build an operating system that fully, completely, and truly matches the concept of "secure by default" and they have the resources, manpower, and ability to do so.
But, instead, they oppose it. Building a secure system is against corporate culture, so they won't do it.
Thanks xBSD!
I have no problem with your religion until you decide it's reason to deprive others of the truth.
I've often thought about how many products use simple programs and stuff to run correctly...like traffic light systems...right now they work pretty well and everything goes together properly. However, the day that cities decide to have a central server run the traffic lights so they can...say, control traffic around accident areas...things will go wrong. The "foolproof" software will cause all sorts of problems.
I don't see this so much as software causing problems as much as the tendency we have to make what used to be simple things really complicated. One example I have in my life is a train system that runs around inside a building by the ceiling at a camp I work at. The system looks really nice..and it could work well. However, having a couple of electrical engineers volunteer their time to make the system made it very different. Now, what could have been a simple on off switch is a whole panel with an LCD display and all sorts of error lights and little IR detectors on the track to make sure the train is in the right place. It is a geek paradise...but the train NEVER works. Despite all the fancy assembly code they have running the whole thing, it doesn't work. An on/off switch would have worked..I'm certain of it!
As we complicate more and more appliances with complex software, there are going to be more problems. Heck..what's gonna happen next time your toaster oven timer crashes...you could burn down a house!
The caveman had something going for them...
The anti-salmon
Moreover, how innovative has MS (or anyone else) been about reliability? Adding new features like embedding full-length motion pictures into Word documents (apologies to Neal Stephenson) is one kind of 'innovation,' but it comes at the cost of gains in stability. One could argue, and people have, that most commercial software is derivative anyhow, and its mass adoption has stifled opportunities to create more stable products.
And finally, do we really need that many new twists on things? I'm not saying stop research or trying new things, but mainframes running COBOL code have been hosting most of the world's financial and business information for decades, and they are legendary for their stability, with low incidence of data corruption and uptimes measured in years to decades.
"Hardly used" will not fetch you a better price for your brain.
10 steps for builidng a successful software product:
1) Fire half (perhaps all) of your programming staff. Most of them don't know know the difference between a heap and a stack, don't have a clue beyond the Java language, and if faced with the prospect of learning x86 assembly language, they'd faint.
2) Hire people that *do* know the difference between a heap and a stack, perhaps have written in some assembly somewhere (even if just in college), and have figured out how to use a few more languages besides Java.
3) When doing #2, ignore college degrees. Whether or not someone has one doesn't indicate whether or not they're a good programmer, at least until our the majority of our school system can actually teach the *relevant* skills.
4) Plan. Plan. Plan. Document. Plan. Flowchart. Plan. Plan. Discuss. Plan. Discuss. Plan. Document. Plan.
5) Code.
6) Discuss. Test. Fix. Discuss. Test. Fix.
7) Refactor
8) Repeat 6-7 until all the software has been reduced to the simplest, most error-free possible codebase for its functionality.
9) QA. (Yup, this happens *after* the testing in (6)!)
10) Ship.
-- sigs cause cancer.
Lots of people don't even WANT reliable sofware - at least, they don't want to pay for it. I'll happily accept my software crashing once a week if it saves me $300 on the cost of what would otherwise be $100 software. The last thing we need is to have the software industry start to look like the healthcare industry, where everyone pays 3x what they should to cover the insurance in case someone needs to sue someone else.
If you need absolutely, positively reliable software for some purpose, than contract with a company who is willing to provide it, and pay the price it takes to get it. But Joe Blo software user should have to foot the bill because someone ELSE wants to force ALL software to be reliable under penalty of multi-million dollar lawsuit. If I sell an operating system designed to let you play MP3s and video games and browse the internet for $99, and you use it you run your mission-critical application that causes you to lose $100 million when it crashes, why should I be liable because you used my (albeit buggy) tool for a $100 million mission critical ap? It's YOUR job to assure that you are using the correct tools for the job, NOT the guy who makes the tools!
It's like cars - just because your transmission goes out doesn't mean you get to sue the manufacturer. You get your transmission fixed if you've purchased a car with warranty terms that allow it to be fixed, and otherwise you pay for it yourself.
paintball