I feel in a similar vein when learning of certain aircraft accidents over the years, where it feels like the redundancy of certain systems and the complexity it adds has been the indirect cause of accidents instead of preventing them. I suppose there's not really a way to quantify the accidents that it's prevent to be able to compare them directly.
Who sits down and determines that 8 is the correct number? Why not 4? Or 2? Or 16 or 32?
So the answer is "some engineers sat down after talking to management".
Lots of mission failures in history were caused by unexpected interactions between fully functional components. Probabilities of failures don't help with that.
https://en.wikipedia.org/wiki/Lockstep_(computing)
Example: https://www.st.com/resource/en/datasheet/spc574k72e5.pdf
> each FCM consists of a self-checking pair of processors.
Even if different teams write software in different languages, they end up creating very similar bugs because the bugs crop up in the complexities of the domain and insufficiencies of the specification.
N-version programming doesn't work as well as you think. See Knight and Leveson (1986).
(N-version programming does guard against "random" errors like typos or accidentally swapping parameters to a subroutine call. But so does a good test suite and a powerful compiler.)
How does a pair determine which of the pair did the calculation correctly?
There's also space systems that use 3 processors and a majority vote for the correct output, but that's different.
Build for various Linux distros, and some of the BSDs. You'll encounter weird compile errors or edge cases that will pop up. Often times I've found that these will expose undefined behaviour or incorrect assumptions that you wouldn't notice if you were building for a single platform.
I other words, how over engineered is it.
(This was when they planned on sending a modular computer with them. In the end they settled for sending up a fully assembled spare computer instead, which made replacement easier.)