What is the acceptable failure rate for software?

Question

Say I produce some software with a genetic algorithm. In order to be certain that the software works correctly in all situations, I would need to test all situations, which could be prohibitively (or infinitely) many. So I evolve the software with evolving test input (some fixed, some inherited, and some random). Now, with each generation, the probability measurably increases that the fittest functions will be general solutions, not just solutions for the known data at hand.

As developers, we are flawed, and our software may fail, in fact quite often. Generally speaking, we have no idea of the probability of failure at any given point, though we may be able to discern specific cases in which the software will fail. All we can do to reduce the failure rate is test thoroughly and practice good software development. But logically, we distribute flawed software all the time.

Would it make you uncomfortable as a developer to know how often your software might fail, but to know nothing about the specific cases in which it might? What failure rate is acceptable? 0.01%? 0.0001%? Would you hold a genetic algorithm to a higher standard than a human when it comes to failure rates?

Answer 1

I'm not sure why it matters if your software is written by a developer or a genetic algorithm.

Somewhere there should be a Requirements document explaining acceptable inputs to the program and the expected outputs for said inputs. You can write unit tests to test small units of the program and business logic. You can have QA testers use the program and execute more complex tests. You should strive for a 0% failure rate within the constraints of the Requirements. Sometimes a client will accept a program with a low failure rate in some situations if they feel it does not matter enough to warrant the extra cost to fix the problem.

Your program does not need to account for every concievable scenario under the sun, only ever concievable scenario as described by the Business Users/Clients/whatever... And if they start having broad requirements that encompas everything under the sun, then you ask them to refine them. There's not much else to say, I think, unless you can give specifics about your situation.

Answer 2

You are asking for a categorical absolute, without providing any sort of context (such as use case, requirements, industry, customers, users, etc.).

Therefore, the answer is a categorical absolute: 0.0%.

If you have a specific context in mind, the acceptable failure rate will depend entirely on the context.

Answer 3

It really comes down to the application.

If the software is controlling a nuclear reactor or an aircraft in flight then the acceptable rate is 0.0%

If the software is providing user comments on a free site with no ad revenue then the lost opportunity cost of failure is pretty close to zero so you could probably tolerate a reasonably high chance - say 5%-10%, and test the specific use-cases which are valuable.

The scary phrase from my (typically embedded) point of view is

...know nothing about the specific cases in which it might [go wrong]

I, perhaps over optimistically, hope that most developers put more design, implementation and test effort into the subjectively important areas of the software.

Say you are designing software for a vending machine. If the 0.1% fault you deem acceptable occurs in the code which decides in which pattern to flash the LEDs when the machine is idle - it's a fancy machine - then I doubt you would even bother with a field change. If on the other hand the fault occurs in the code which decides how much change or how much chocolate to provide then you have a much bigger problem.