MTBF, or "failures" in the 6σ sense
While these are completely different things, they share some common properties which apply to your problem.
The Mean Time Between Failures is a commonly used measure to assess the reliability of things. If, for example, you buy something like a car or a harddisk, then that particular thing may work without any problems until the day you die. But on the average, it will eventually encounter failure, after an average time X. That's the MTBF.
Six Sigma (6σ) is basically the same kind of thing, except for the most part you do not deal with things but with processes, and you analyze (and optimize for) not the operational time, but the number of "opportunities", which may be... whatever, and failures, which may, again, be... whatever. This can be about producing something, delivering in time, or just answering a phone correctly.
In a more concrete example, if e.g. your shoe factory produces one million sneakers per month, you are trying to achieve that no more than 3 of them (ideally zero) come out with the wrong color or without shoelaces, and cannot be sold.
How does that apply here?
The MTBF has a well-known implication, it goes down proportionally with the number of units used going up. Which means that although it is very unlikely that your cellphone will explode in your pocket during two to three years of typical usage, it is practically guaranteed to happen to someone if ten million people own one (that was the reason for e.g. Samsung's infamous recall campaign / PR nightmare a year or so ago -- it's not like you were really in danger if you owned one).
Similarly, looking at it from the 6σ angle, if your shoe factory produces not just one million sneakers, but one billion, then you will have 3,000 defect pairs of shoes, not 3.
A few years ago, RAID-5 was discouraged from being used. How so, it provides extra data safety, doesn't it? It so happens that harddisks have a very, very small chance of corrupting a sector so it's unrecoverable. That never happens... well, almost.
But if your disks are large enough (as modern disks are), with many sectors, and you have several of them bunched together, you are basically guaranteed to have it happen during a re-sync operation, i.e. at the precise time when you just don't need that to happen because you're already down one disk. Plus, you have the chance of a second disk catastrophically failing half way down the re-sync. Which also never happens... well, almost. The more disks, the more likely it is to happen.
The same applies for re-implementing the same functionality in a software many times. Each implementation (every function, not just the ones that duplicate functionality) is one "opportunity", or the equivalent of a harddisk. More functions, via duplicating functionality, means more opportunities for failure. Plus, more code to review.
While your programmers are mostly working error-free (well, hopefully), there is always a tiny chance for them making a false assumption, or an outright mistake. The more opportunities given, the more likely it is to happen.