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?

  • The industy seems to think that it is somewhere between 75% and 80% . – deadalnix Oct 12 '11 at 16:08
  • 5
    In nature, things created by genetic algorithms actually have a very high failure rate. However, that doesn't mean those things aren't useful. – Scott Whitlock Oct 12 '11 at 16:08
  • 1
    You don't say if "all sitautions" means "all situations as defined in Ye Sacred Tome of Requirements ", or "all situations we can dream up, including but not limited to attack by fire-breathing radioactive manatees, zombie apocalypse; or accessibility issues for beings from Graglxxon 9". – FrustratedWithFormsDesigner Oct 12 '11 at 16:24
  • @FrustratedWithFormsDesigner: Good point. I was thinking only in terms of requirements: they generally have provisions for some exceptional conditions (no Internet connection) while leaving others unspecified (user has become a zombie and lacks the cognitive capacity to use a doorknob, let alone a keyboard). – Jon Purdy Oct 12 '11 at 16:35
  • 1
    Failure rate of what? The strategy logic of one monster in a free game has a much higher acceptable failure rate than the launch controller of a nuclear missile. – Loren Pechtel Oct 12 '11 at 20:44

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.

  • I guess the only difference is in what you know. Like the Heisenberg uncertainty principle, you can’t predict both the rate and the position of failure. – Jon Purdy Oct 12 '11 at 17:00
  • @JonPurdy: No, you can predict them both if you know the inputs and you know how your system behaves. – FrustratedWithFormsDesigner Oct 12 '11 at 17:01
  • But if your software is evolved, you don’t have a say in the points of weakness. You don’t have any say in the internal structure of the program, and it will change unpredictably with every generation of improvement. – Jon Purdy Oct 12 '11 at 17:07
  • @JonPurdy: Ah ok, now I think I finally am starting to understand what you're getting at. You're right, if the code is a black-box and you don't understand it's internal behaviour, you will only have unit tests to predict possible failures - but if your unit tests cover all required use cases, you can still predict how it should behave in required scenarios. – FrustratedWithFormsDesigner Oct 12 '11 at 17:39
  • Alright, so I guess I have my answer: 0% failure for known requirements, and cross your fingers if you decide to use it for something beyond its design. – Jon Purdy Oct 12 '11 at 17:57

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.

  • 1
    You could be proactive and offer examples. “It depends” can be a perfectly valid answer. – Jon Purdy Oct 12 '11 at 16:18

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.