What exactly do they mean by this? If each of the 3 versions had exactly one bug, isn't this just a weird way of saying the first 2 fixes either didn't work or introduced a new bug?
The SRR (software readiness review) process happened after development but prior to certification for launch. Most of the bugs were found here and were found to have existed in the code since the beginning of the program.
These were overwhelmingly low severity discrepancy reports.
If I recall correctly, there was a time when they were finding lots of bugs through SRR, so the main development team started their own "continuous review" designed to catch bugs before going to SRR. This made the SRR people angry because they were finding fewer bugs and felt the development team was focusing on competition over bug numbers rather than the code itself.
This reminds me of the Quality culture, at my last job, which was a famous Japanese optical corporation.
It was deliberately set up, so there was an adversarial relationship between QA, and Development, with QA holding the aces.
As a Development manager, it used to drive me nuts (Ed. Well, it wasn’t much of a “drive.” More like a short putt). It did result in very high-Quality software, but at the cost of agility.
It reflected their hardware development methodology, which regularly resulted in stunningly high-Quality kit, but I think caused a lot of issues with the usability and effectiveness of their software.
I rather it be built right, than quickly. I wish we held quality to higher standards in the software industry.
We share a wish.
The claim that a codebase of 420k lines contains "only one error" is of course absurd, and the members of this forum would laugh anyone out of the room who made such a claim about any other project, pointing out how they cannot possibly know, actual logical contradictions in the claims as described by GP, or just plain ridiculing it without further elaboration.
But since the code in question cannot meaningfully be tested by the public, and people have been indoctrinated to believe the myth that aerospace engineers are an entirely different species that doesn't make mistakes in the sense that the rest of the workforce does, the hubris is accepted until disproven, which it probably won't be for various practical reasons.
Nevermind that the Space Shuttle was a death trap that killed two crews, and that the associated investigations (especially for Challenger) revealed numerous serious issues in quality and safety management. People will continue to just nod their head when they hear nonsense like this, because that's what they have seen others do, and so Schrödinger's Hubris can live on.
I doubt any of the people who actually write the code would stand by when that claim was made and not clarify it to 'we only found one bug'.
1) edited
Formal proofs may not be silver bullets, and we’re never safe from a faulty implementation of the proven algorithms, but this quanta article on a DARPA project showed impressive results [0].
There’s also AWS’ use of TLA+ [1].
[0]: https://www.quantamagazine.org/formal-verification-creates-h...
Many (most?) non-trivial bugs are actually flaws in the specification, misunderstandings about what exactly you wanted and what real-world consequences arise from what you specified.
You also aren't safe from misunderstanding what it is that you've proven about the program.
Which is actually the same problem as other software bugs; you have a specification of something, but you don't know what it is that you've specified, and you wish it were something other than what it is.
Interesting to think about a formal code verification system that maintained a connection between all four prime artifacts: natural language description of problem as understood & intended solution, vs. code and the properties actually verified.
And then someone tries it with a ulimit of 16kB.
Does it run?
Do you _know_?
Do you even know what is correct behavior in this situation?
Sugar in the tank is an agreeable example because of how obvious it is, but what about something more subtle? An odd condition that leads to the wrong resonant frequency. An unknown software bug that makes the brakes lock up on Tuesdays at 12:00 AM on one specific backroad in a remote part of Virginia. The combinatorial possibilities of operating conditions are too numerous to exhaustively test.
I guess you could say that every function has every quality that it happens to have, so that functions need only exist in order to be “correct.”
Of course now the greatness of the feat depends on how much testing there was between versions, but given that it was the shuttle there was probably a lot.
Fixing a bug in 10,000 washing machine control boards is very expensive when it entails sending a technician to every house to replace the circuit board.
We didn't apply anywhere near that kind of quality control to smartphones or VR headsets. Once users are trained to install OTA updates to fix issues, most of the impetus for extreme quality control outside of the bootloader->OTA update path is gone