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

Comments

But how...

[C.Maggard]

...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?

Re:But how...

[Anonymous Coward]

NASA's designing cutting edge, one-off product for employees fully aware of the dangers. Software companies rely on consumer ignorance, knowing lawsuits aren't as likely against new and unfamiliar tech. They don't know software can be reliable and secure, believing, as another poster wrote, reboots, registry creep and viruses are normal. Get ready to see EULAs overturned once software is seen less like NASA and more like the familiar, necessary and integrated into daily life cars and appliances.
We don't stand for unsafes car or leaky microwaves today for the sake of innovation, future consumers won't stand for 'feature rich' software capable of billions of dollars in damages. How OSS will adapt is anyone's guess, but you can bet it's coming.

Re:But how...

[morleron]

Evidently Microsoft thinks it's very difficult or impossible. Given their track record when it comes to being truly innovative, instead of just buying or stealing the technology, I believe their assertion to be true for MS. This is one area where I think that the Open/Free Software community can make a telling case against MS. Our products are known, anecdotally if nothing else, for being much more stable and reliable than those of the Redmond monopoly. Given the recent study that showed far fewer errors in the Linux kernel TCP/IP stack, we now have some facts to back up our claims.

I think that it behooves us to push for greater software reliability. I'm sick and tired of the proprietary software concerns that can get away with a warranty that essentially limits their liability, even when the software fails to function, to "we'll replace the CD or floppy if it's defective." It's time that the software industry be forced to live up to the reliability and liability laws that other industries must abide by. I would prefer, given my libertarian leanings, to see this done without resort to new laws and some new government department. However, given the monopoly conditions that most of the industry operates under that may not be possible to achieve.

Just my $.02,
Ron

Re:But how...

[JimDabell]

You as a programmer may benefit from this, but most customers will not.

That depends on the size of the company. For small companies, I agree. For larger ones, hiring a contract programmer for a month or two could be cheaper than the alternative.

Rarely do "customers" know better than the developers.

I agree. However, the customer will have more of an incentive to fix the bug that is causing them grief than the original vendor will.

Furthermore, I would say most web developers would benefit little from IE coming with source code.

I was using my particular situation as an example of how people must rely on proprietary software for *mission-critical* purposes. I wasn't implying anything about web developers in particular.

microsoft would have to agree to incorporate the fix for it to be worth anything...

No. I'm not referring to bugs where a developer has to deal with the lack of, say, attribute selector support in IE. I'm referring to bugs whereby there is a problem with IE that prevents me from relying on it - i.e. it refuses to run on my particular machine. If you'd like a different example, consider before Y2K. An organisation uses a mission-critical application all day long, but when Y2K rolls around, it refuses to work. They can't fix the bug because nobody has the source but the vendor, and the vendor has no reason to fix it, as they are no longer selling the application, made the programmers involved redundant, and so on. They might not even have the source themselves.

A fork for every bug is not going to improve any software.

The aim is not to try and graft on an open-source development model. The aim is not to improve the software; it's merely to have a get-out clause when the original vendor screws you. In the Y2K example, for instance, an independent contractor could fix up the application and sell it on at a marked-up price.

The vendor gets 110% for writing buggy software that others need to fix? Or do you mean anyone who calls themselves a vendor can get the software for free?

Perhaps this was a badly thought out option. The intent was to provide a way of third-party bug fixing, without giving out the source to every customer, maintaining revenue for copies sold, yet discouraging "forks" where somebody could sell a superior version and take over the original vendor's market.

[About being unable to disclaim liability] Unfortunately for most developers/vendors, this will read, "Be unable to distribute software".

That's why the other options exist. I'm not sympathetic to people who claim their business will be hampered by disclosing source code - the expensive part of development is not some radical new way of writing a function, it's the project management - and unless somebody directly violates copyright, disclosing source code will not help competitors.

It's a vicious circle

[Ed Avis]

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'.

Re:It's a vicious circle

[sasami]

The trouble is, the more accustomed users become to bugs, the harder it is to get them reported and fixed.

This is absolutely and shockingly true. Microsoft is almost singlehandedly responsible for the widespread cultural mentality that faulty software is okay.

You'll find this notion all over the place but the worst part is seeing it in the upcoming generation. I work with teenagers, bright kids who are totally immersed in technology. Yet almost none of them understand why I complain about Windows all the time. If I tell them that a real OS doesn't crash and is not permitted to crash... they laugh -- or glare -- and say, you're crazy.

--
Dum de dum.

It really depends upon the product

[conan_albrecht]

What's wrong with flashy stuff for somethings? I like flashy (i.e. sometimes buggy) software for my laptop. I don't mind if my beta-version browser crashes once in a while because I get the new features.

My servers, OTOH, are another story. I wouldn't use anything but Debian (for linux, that is) because it is incredibly stable. My two Debian boxes on woody stable run 2+ yr old software. Guess what? They don't crash. I didn't upgrade from potato right away, but waited a little while.

Consumers are generally willing to accept more buggy software because they don't run servers. So what if Word crashes once in a while? Most consumers are so conditioned to it that they don't think another thing of it.

I realize that mail servers, electricity systems, and space probes need stable software, but most consumers don't administer these things. They use browsers, email, and cell phones that don't cause (much) physical harm when they crash.

Sad. So very sad...

[mcrbids]

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!

Re:Sad. So very sad...

[Ian Bicking]

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.

I think you dramatically underestimate the work in creating a secure, robust system.

First, Microsoft's money only buys them so much. You can't just put more money into something and get more out of it. Of course, they can pay to hire the best people and the supporting staff to keep those people focused. But it still takes time.

But even suppose MS invests not just money, but also time in this. Can they really achieve what you think they can?

Security isn't as hot as people seem to think it is. Security is usually a compromise -- increased security usually means a system is harder to work with. Maybe there's ways around the difficulties of working in a secure system, but there's no conventional, proven solution. And security is a system, not a single piece of software.

The same goes for robust operation. You can decrease the complexity of the system through partitioning, but that also makes certain functionality more difficult. Coming up with the right partitioning is difficult -- it's a factoring problem, and factoring a program (or system) is not something that has a Right Way. Factoring depends on backward compatibility, current features, and most impossible to get right, on future features.

And partitioning is a compromise as well. The more you integrate things, the easier they are to automate and control, the better they work.

Then there's the extensibility of the system. So long as you don't control the system entirely, bugs can creap in. The deeper the extensibility, the deeper the bugs can be -- including hard crashes and security holes. Microsoft doesn't create an insular system, and that's not just some bizarre corporate culture.

The problem isn't a lack of resources. It's just a hard problem.

I've thought about this before...

[fjordboy]

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...

It won't stifle innovation...

[Macrobat]

Holding software liable for failure won't stifle innovation. A great deal of (most?) innovation goes on in academic settings anyhow, where results are published and critiqued by outside experts (i.e., from other universities), not hidden away like some Special Sauce recipe.

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.

How to build reliable software

[ZenShadow]

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.

Re:How to build reliable software

[ZenShadow]

I said *have written in* assembly. Not *will continue to write in* assembly.

The point of knowing assembly on the target platform is not due to some misguided plan to build the project in assembly. Hardly realistic in today's world. The reason for it is because most anyone who has ever successfuly written a program in any assembly-level language, will understand vaguely how the machine works.

That's the point. As a person who is tasked with hiring a staff to write software, I don't give a damn about a college degree or whether or not you know Java. I want to know if you understand the machine in general -- because if you don't, you're pretty much guaranteed to write crappy software.

But then, most people that respond with comments like this typically fall into the Java programmer category...

--ZS

Re:How to build reliable software

[arkanes]

A college degree is only as good as

a) the college who granted it
b) The degree to which the philosophy of the people who designed the curriculum matches yours
c) And, most importantly, the student who took it. Since, given the modern US education system (I'm not familiar enough with other countries to judge), a degree at any level less than a Masters or PhD does NOT mean you've actually learned the skills - it simply means you can pass the courses. Those aren't the same thing at all.

Being a good programmer requires alot more than a dozen classes. There's a mindset involved thats not common and hard to teach.

On top of that, software is something new. It's not well-defined and proven the way most other disciplines are - it's common, for example, for ground breaking new work in software to be done by amateurs. To cut yourself off from that because you insist on a piece of paper that doesn't neccesarily guarantee skill is stupid.

Re:If they wont let you fix it...

[Steveftoth]

no, but you could at least get a second opinion from a better educated source.

Right now, with CSS (Closed Source Software) all you have is second opinions based on ancidotial evidence. The evidence that software X will work for you is only as good as what other people have done with it. At least with OSS, you can pay an expert to help you get an educated second opinion, and see if the software can work for you.

OSS is not the solution to the problem but rather it can help you decide if software can work for you. And probably for the general case, most people can trust the MS verdict on what their software can and can not do. But if you are doing something strange and experimental with say MSSQL, you can't rely on what they say. In that case it might be a better choice to use an OSS product that you can see the source and have a better indicator for predicting what the software will do.

Software reliability on NT

[Anonymous Coward]

I guess I've had a different experience with reliability than most of the posters here have had.

Given a piece of software that has both Windows and Linux versions, the Windows version is almost always more reliable/less buggy.

The Linux version usually seems to have been done as an afterthought, and most of the development work goes into the NT product.

I'd like to choose the Linux version everytime, but for most software, the Linux implementation just isn't there yet.

Let's be realistic

[phillymjs]

As long as companies like Microsoft are around to pump money into lobbyist firms and election campaigns, we'll never see a software-reliability law that's actually beneficial to consumers.

I'm pretty much willing to settle for some sort of truth-in-software-advertising law... so when William H. Macy's voice tells us that Microsoft's server software is totally secure and reliable, it also has to tell us that Microsoft's EULA says that if this turns out not to be so, tough shit on you for believing it in the first place.

~Philly

Re:Slightly disingenuous

[91degrees]

I agree. Most software is very reliable. More aircraft crashes are caused by mechanical problems than software issues. If there is a life threatening fault in a piece of software, this usually results in a recall. The only software that's really unreliable is consumer level, and you are quite unlikely to die from Word crashing (even that doesn't happen to me much).

Is there a downward trend?

[bcrowell]

Is there really a downward trend in quality? How should we measure quality?

I started using computers ca. 1979, when my dad got a TRS-80. I don't remember ever encountering a single software bug on that system, although the hardware certainly had its problems.

But does that mean that quality is getting worse? The OS on that machine was on ROM, and was about 4 kb. A modern OS weighs in at many, many megabytes. It's possible that the number of bugs per line of code has actually been going down.

Another possible metric is how often the user encounters a bug. By this metric, non-OSS consumer-level software has certainly been getting much, much worse. I switched to Linux from MacOS, and my average number of bugs encountered per day went from maybe 5-10 to some number less than one.

Some things have definitely changed since 1979:

• In the early 80s, software mostly came as BASIC source code. If you encountered a bug, you could fix it.
• Software houses used to be much more open about bugs. I briefly worked on tech support and quality assurance for Digital Research around 1983. We had a list of known bugs in each product, and we would fax customers the list on request.
• Performance is much worse. A TRS-80 would boot in a matter of seconds, whereas today the Windows boxes at my work take up to 3 minutes. The first word processor I ever used, Electric Pencil, started up in a fraction of a second, and never had any noticeable delays in handling input. This was on a CPU a hundred times slower than current ones!

Re:Cutting Edge software - Debian?

[DietHacker]

"Because software needs to be thoroughly tested before it can be called reliable. "Cutting edge" software tends to be poorly (relativly speaking) tested, since it hasn't had that much time in the real world."

This is circular. You nearly imply "cutting edge" is not reliable by default. This is a mistake. If there is a market demand for reliability on the consumer level, then it may need a cutting edge solution: New diagnostics or testing mechanisms. Perhaps OSS is that cutting-edge methodology and it simply has not caught on everywhere.

the notion that...

[zogger]

..the notion that vendors would be liable for *bugs they know about* has some merit. Think about it. If the large companies-we'll pick on MS because it's such a good example-were forced to fix bugs in a timely manner, then they would need to accept bug reports. They would also have to release bug reports as soon as they knew about them, ie, they couldn't sit on a critical exploit and let people hang out in the wind for months and months. Once a report was made to them, it would then become an official bug they couldn't ignore. They'd have two choices then, switch to open source to find as many bugs as possible in the shortest time, or keep paying claims forever because they ignored bugs. Either way they would release less of better quality, not really a bad idea. If they wanted to hire professional beta testers, so what? More paid jobs. I don't see that as being all that bad. Nope, I don't.

Open source -FOSS- is in a unique position because it's "free". There can't be any damages if you haven't paid for it, or at least that could be part of "the law" written into it.

Normally I'm against new laws, but instituting some sort of consumer protection should be in order, if these companies want to make serious profits all the time. There are very few examples of consumer products out there that have no liability at all attached to them. With just a short time reflection on it, I can't think of any off hand, just *some* software. Eventually it's going to happen, so better to sort it out now, it really should have been sorted out 30 years ago, IMO. I tell you what will cause it too, if it's not done voluntarily in advance and adhered to, the first uber killer mass virus or trojan that makes code red or slammer look like a case of the sniffles, a net-killer. You'll get ten times worse legislation out of washington if the software community waits until that happens.

I'd say it's bound to happen sometime, too. The article cites 50 some odd billion a year already in losses due to either bad or insecure programs, you have something bad happens that does ten times that in one day or something, you WILL see the mother of all knee-jerk reactions from "the software consumers".

Well, OK, say that "something" is needed - What would be reasonable, but still not stifle development? One would be outright sales of software, not just renting -licensing of software. You buy it, you OWN it. You get it at such and such a date, as of that date it worked as advertised, after that date, well, up to the vendor then, anything "new" that needs to be added is up to them, from free unlimited patches and updates to pay-for individual bugfixes and exploits as you go, forever. Could be a yearly lease thing, whatever. For-profit vendors would get on the ball pretty quickly then if they charged too much or it didn't work all the time. they'd be forced into auditing as the most important part of production. Hmm, is this a bad idea really? The software is sold as "works on this and this, won't work with that and that". Yes, that would make software developers tend to work around just a few pieces of hardware and one or two OSs max no doubt. It would also be very expensive. Very expensive. Maybe people would go to the no liability but free stuff then? And I can see various versions in between those two extremes.

Could there be set limits per incident? Perhaps. Max liability, perhaps.

How about classifications of software?

"Entertainments" might be of lower criticality (so less liable in terms of maximum cash) then say the pacemaker software, or auto-controlling software. "Communications" like browsers and email and chat would be in the middle someplace in those terms of criticality. If your business depends on UPS or FEDEX to ship widgets, and they constantly don't get there or they are smashed, those companies would be sued out of existence. but if your widgets are electronic, well? It's just your tough luck as the consumer then, the software and the infrastructure has let you down, but they all get to say

Not if they do it right

[Sanity]

It sounds like they are proposing that people will only be liable for bugs that they know about and don't disclose - not exactly a serious problem in the Open Source world.

Forcing companies to disclose bugs in this way could only serve to allow users to make more educated purchasing decisions on the basis of software reliability.

Imagine that I wrote some software that I *knew* was buggy, and then sold it to a hospital or into another situation where people's lives were at risk. Imagine then that one of the bugs I knew about before selling the software killed someone. Why shouldn't I be responsible for that?

And even worse...

[raehl]

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.

What they should do...

[Anonymous Brave Guy]

All this will do is make them add a clause to the shrink-rap EULAS "I accept responsibility for any loss off blah blah as a result of software defects"

What they should do is remove any legal weight from clauses along the lines of "This software comes with no warranty of any kind, including fitness for any particular purpose..."

If you're taking my money for it, it should be fit for something, just the same as any other product, and just the same as any other sales pitch, I should be given a fair and accurate description of what the software I'm paying for is or isn't fit to do.

Part of the problem here is that most people on this thread seem to be thinking in absolutes: "if Word crashes, I can sue MS for [evil grin and pinkie finger to mouth] one million dollars!" It's not about 100% reliability, it's about reliable enough. A word processor doesn't need to be bug-free, it just needs to be reliable enough to write my documents under normal circumstances. MS might reasonably be expected to pay some compensation for excessive downtime due to their carelessness with the recent product activation issue, but not if Word crashes because of some incompatibility with other software on your machine about which they can do nothing.

Surely it should all come down to fair and reasonable marketing claims (don't say it's 100% reliable if it ain't) and fair and reasonable compensation when those claims are found to be erroneous (if you said it was in good faith, but it turned out not to be, you give me back some reasonable amount in compensation, depending on how effectively you addressed the problem once it was discovered).

If you want 99.99999% up-time for your server, you can buy from someone who claims to provide it, paying whatever the going rate is for it, and expect to get it (or compensation). However, you aren't entitled to assume that WinXP is suitable for running operating theatre laser surgery algorithms "just because" and then sue MS when it doesn't live up to the job you've foolishly given it.

Re:Why should...

[Fulcrum of Evil]

why should an electronic engineer who designs a program to operate the gears be exempt?

• Because none of his development tools are sufficiently accountable to trust.
• Because he is paid less than a plumber - he can't afford to be bonded on the wages you're willing to pay.
• Because nobody is set up to bond programmers.
• Because nobody wants to pay for quality.
• Because guaranteeing the correct operation of a complex piece of machinery in an uncontrolled environment is idiocy. At least a manual gearbox leaves evidence when it gets overtorqued.
• Maybe the safety interlock wasn't in the spec.

As an electronic engineer, I make my system based on some OS, so either I or the OS manufacturer (which, I add, licences an OS, if it is used against the license terms, it is my liability) has the liability.

What are you really? electronics engineers build circuits and hardware. Programmers build on top of an OS. Unless you got a RTOS, you almost certainly got no claim of correct operation. You really want to warrant that MS or Sun makes a bug-free product?

Re:Why should...

[dubious9]

Programmers build on top of an OS

Not always. There are alot of embedded applications where there is no operating system at all. Each program would function as its own operating system. There is overhead with OSes and sometimes you don't need the functionality. When you have simple hardware with a simple interface, dropping the OS is a good option.

Also, I'm pretty sure the software that runs air traffic control or cars has a chain of responsibility going back to the programmer.