I have no idea what you mean by fatalistic, and I don't think you're in a position to predict my thought process. Bugs exist because it is not possible for any

I have no idea what you mean by fatalistic, and I don't think you're in a position to predict my thought process. Bugs exist because it is not possible for any one human or even organization of humans to know all of the ways in which the software is buggy. Worse, in the limit, there's not even a clear distinction between a bug and the absence of a feature. If your software is in English, then that's a bug for someone who speaks Polish. If your software has any linear time algorithm, then that's a bug for anyone whose input is large enough to cause that to algorithm to produce an unacceptable delay. What's unacceptable? Depends on the user. If your software allocates memory, then eventually that memory allocation will fail because there wasn't enough memory, and that will be a bug. It'll be a bug even if your software reports the nicest possible error message. If you say, "sorry I couldn't execute your image filter because I ran out of memory", then that'll be a bug to the poor fellow who needed the image filter to finish executing. If your software uses color to convey data, then that's a bug for someone who is color blind. And so on! And then there are security bugs. Security bugs exist, in part, because it's not possible for any mortal or organization of mortals to predict the entire decision tree that software of any meaningful complexity is executing. There will be some rotting branches in that tree, not because of ship dates or lack of trying, but because code that has enough control flow in it will have too many paths for anyone to reason about. Finding the one path that is broken is way easier than proving that no such path exists. Some of my favorite bugs are the ones where everyone thought that the OS or CPU or compiler must do one thing, but they simply did not know that the thing that was expected is in no way guaranteed. Sometimes to discover the bug requires extreme acts of brilliance. Spectre is a fun example, and there will be more things like Spectre in the future (and I don't mean more timing side channels -- I mean there will be an entirely new thing, that isn't due to timing and isn't a side channel, that we will learn was wrong with computers all along). And say that you try to solve this with formal methods. That will require a specification. I guarantee you will get the specification wrong, for all of the same reasons that I think you would have gotten the software wrong. That's not to say that formal methods aren't useful -- they're incredibly useful because they force you to state what the software is doing twice, in different forms, which hopefully enables you to catch bugs by detecting inconsistencies between the two statements about the software (the statement that is the spec an the statement that is the code). But then there will still be a bottomless well of bugs in those areas where the spec and the code both got it wrong. I guess Spectre was a case where everyone's specification of the CPU was wrong. It's super unhelpful to frame the presence of bugs as an issue caused by the need to ship. That might be true for some bugs, but it misses the point. Bugs creep in any time code gets written. If you need to write code to fix a bug, you'll just introduce another bug by fixing the other one. So if ship dates were pushed back to infinity, then at infinity, you'd still have bugs.