[SystemSafety] N-version programming moves the goal posts
Steve Tockey
steve.tockey at construx.com
Wed Jun 10 20:10:05 CEST 2026
Derek,
In 1990, Susan Brilliant, John Knight, and Nancy Leveson published,
“Analysis of Faults in an N-Version Software Experiment”
In IEEE Transactions on Software Engineering (vol 16, no 2, Feb 1990).
Clearly the participants were all human developers. The conclusion they drew, however, was that N-Version programming by humans was not that beneficial because the different programmers all tended to make the same mistakes. So one line of reasoning could probably be this:
1) As shown by Brilliant, Knight, and Leveson in the 1990s, human developers tended to inject the same kinds of defects into the code they wrote
2) Based on the kinds of repeated defects they reported, there is probably no valid reason to believe that any of that has changed since the 1990s, meaning most existing code today suffers from those same common defects
3) LLM-generated code comes from models that have been trained on contemporary, available code and thus, is trained to include those same common defects
Why should anyone expect that LLM-generated code would NOT suffer from the same commonly-repeated patterns of defects that have always been there?
Then you wrote, “So the correctness issue has now shifted from the code to the specification.”
I counter-propose that the correctness issue has ALWAYS been in the specification. Code can only be correct with respect to some specification, it cannot be its own definition of correctness (despite what Microsoft and others would like to claim). Incidentally, the most common defects found in the Brilliant, Knight, Leveson study included things like boundary conditions (“corner cases", "edge conditions”) that were unspecified and thus not properly addressed because they did require special handling. So even their results can be seen as pointing a very clear finger at incomplete and/or ambiguous specifications.
I believe the critical question has always been, and will continue to be, “what is the form of a specification that would give the highest probability of resulting in correct code?” without regard to whether the code would be generated automatically by some machine or manually by some human. In the end, both producers of code would need the same kinds and amounts of detail.
— steve
On Jun 10, 2026, at 5:20 AM, Derek M Jones <derek at knosof.co.uk> wrote:
All,
N-version program is a great idea, but it is is also a lot
more expensive. At least until LLMs came along.
This paper
https://arxiv.org/abs/2606.07828
creates five implementations of a 23k line specification.
Five different languages were used for the implementation,
but that is just for bragging rights.
So the correctness issue has now shifted from the code to
the specification.
A few months ago an LLM generated a C compiler. The compiler
did very well on correct code (which is the vast majority of
the training data), but very badly on incorrect code.
https://shape-of-code.com/2026/02/22/investigating-an-llm-generated-c-compiler/
--
Derek M. Jones Evidence-based software engineering
blog:https://shape-of-code.com
_______________________________________________
The System Safety Mailing List
systemsafety at TechFak.Uni-Bielefeld.DE
Manage your subscription: https://lists.techfak.uni-bielefeld.de/mailman/listinfo/systemsafety
More information about the systemsafety
mailing list