Mike Beede wrote:
On problem with solving something like this is that you have to
test the results to see if they're correct. A good--though
expensive--way to do that is to have multiple versions of
the program each developed independently, and compare their
results.

That works much less well that you'd think.

It would be facile to say that different development teams all make the
same mistakes, but this happens surprisingly often. Every good QA
engineer knows about "buffer overruns", "off-by-ones", "numeric
overflow", "unverified user input", "deadlocks" and a dozen other
mistakes often made by programmers.

The topic has been seriously studied. To make n-version programming have
any value, you have insure the various teams have very different types
of people, different management philosophies, and significantly
different specifications. (NASA did this with the primary and backup
Shuttle flight control software.) After all of this, we come back to
your point about then having to test the various versions and when they
disagree, figure out which one (if any) is correct. If two of three
versions agree, that doesn't mean those two are correct.

The actual value of n-version programming has been studied in depth by
Nancy Levenson. You might want to look up her papers.
--
Kevin Willoughby lid

It doesn't take many trips in Air Force One
to spoil you. -- Ronald Reagan