This reminds me of a story I heard a long time ago in my mainframe days. (Bear with me if you don't know what a mainframe is. )
In the IBM mainframe operating system known (then) as MVS there was a fantastic utility program called IEFBR14. It was so named because all it did was branch to the address in register 14 (BR is the IBM assembly language mnemoinc for the operation "branch to address in register"). Register 14 in mainframe programs was by convention the address of the next intstruction to be executed in the program that called this one - that is, the return address. So, essentially, IEFBR14 just returned control back to the caller.
IBM also used register 15 (by convention) as the "condition code" or error code indicating the outcome of the program call. Typically a zero meant "all is well" while other values like 4, 8, 12, etc., indicated something did not work as expected (or at all). When one program calls another the value in register 15 is usually unpredictable - rarely zero.
The way IBM batch jobs worked was that prior to the execution of the program specified in any step of the batch job, all the dataset (file) allocations required for the program were done. IEFBR14 was a great little do-nothing utility used to create new datasets or delete old ones.
The first version of IEFBR14, as the story goes, was simply one instruction (in assembler, BR 14: that is, branch to the address in register 14). (A "register" was one of 16 temporary storage locations used by a program for things like mathematical operations, addressing, etc.)
That was a bug: the called program is supposed to return a condition code in register 15. Because that didn't happen, the return code from IEFBR14 could be almost anything - when in fact it should have been zero. The non-zero condition code (often used as a check in batch jobs to determine whether the next step should even be executed) could cause all kinds of confusion, especially for a program that presumably did nothing.
The bug fix expanded the program to two lines of assembler code - the new first line of the program cleared register 15 to ensure that IEFBR14 always returns a condition code of zero.
SR 15,15 (subtract the value in register 15 from the one in register 15, storing the result in register 15)
BR 14 (branch to the address in register 14)
My point is this: all software has bugs. Maybe a particular program has been thoroughly debugged over the years but if you're waiting for that bug-free operating system or software package you're going to be waiting a long time.
(I don't have any way to verify this story, nor do I know the origin of it. It could be just another urban (computing) legend.)
All non trivial software has bugs. That is a fact of life we must accept. I understand that NASA has a development procedure that greatly reduces the incidence of bugs, but doesn't eliminate them. The problem is that it is very expensive, prohibitively so for a commercial software company. Only where the cost of software is a small portion of the complete project and the consequences of failure so serious can the cost be justified.