As a user of software, I get similarly frustrated as the author. ("user" here includes use of third-party libraries to build on) However, developing system-level software, I've come to realise that even if you really, really care about the quality of your software, you can still be bitten by statistics. Basically, developing error-free software is comparatively easy if your software effectively performs no I/O, that…
As someone who works on compilers for a living, even “read in some data on launch, grind through some computation, emit output, terminate” is not an easy problem. Regardless of what tools you use, there are no substitutes for testing, care, and rigour. And testing.
I would not be surprised if compilers were the most complex examples of that kind of program in the wild. Still, I would be surprised if automated testing of a compiler was as difficult as, say, test cases kernel-space driver that simulate hardware failure. (this is one example of something I'm currently dealing with) This is probably why compilers tend to have comprehensive test suites, and why drivers (and other I/O-heavy software) usually don't. To be clear: I'm not saying writing compilers is easy; I'm saying automated testing of compilers is conceptually not that hard to imagine, so it gets done. Whereas testing I/O and other external interaction involves ridiculous levels of yak shaving as it has almost no existing tool support, so it doesn't happen. Yet, most of the software we as humans interact with directly is exactly that I/O-heavy stuff.