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 is, it behaves like a program in a computer science paper: read in some data on launch, grind through some computation, emit output, terminate. Barring catastrophic hardware failure of CPU or memory, this is a nicely deterministic programming model. You stand a chance writing correct code.
Throw "real" I/O into the mix, and almost anything can fail in weird ways, and your code has to be prepared for it. Network I/O is guaranteed to fail sooner or later while the developer is using the software. So it usually gets taken into account in some way, usually only distinguishing between "there is no connection" and "there is a connection". There are a myriad of other cases in between that are usually not even considered.
Disk I/O can fail for a variety of reasons. Not just hardware failure; file systems aren't perfect, especially when confronted with power failure, kernel panics, etc. Randomly flipped bits happen. (yes, really)
Not only are there are bugs in the GUI framework you're using, other GUI programs are running at the same time and they can inadvertently interact with your program due to the shared GUI framework use.
Other programs can inadvertently interact with yours in other ways: locked files, claimed sockets, contention for any kind of resource, race conditions, thread/task scheduling - you name it.
Timing bugs are ubiquitous. Everything you do in your program takes >0 time. Maybe on your system, with your data set, it looks like 0. Maybe because it takes slightly less than one video frame's worth of time. On your customer's system, it takes longer. If they click something before your operation has completed, and you haven't anticipated this, your program will fail in weird ways. Where I live, I can't get an internet connection with less than about 80ms latency even to the nearest servers, let alone to North America, where most servers sit (more like 200ms). You wouldn't believe how much software handles this terribly.
The problem is complexity - in many cases, unavoidable complexity, not the accidental complexity us developers keep railing against. Most of these error cases are extremely rare. The thing is, with thousands or millions of people using your software, extremely rare bugs suddenly become a very frequent occurrence!
Yet the tools for dealing with this kind of thing are somewhere between terrible and non-existent. There are some tools for simulating difficult network conditions; those are comparatively easy to make. I'm not aware of similar software that simulates OS API call failures. Or a "file system from hell" that wreaks havoc with your file I/O. Fuzzing a program in such a way would likely uncover countless bugs. valgrind and its myriad of plugins are great, but as developers we almost certainly under-use it.
Developing such tools is obviously expensive, and even they won't catch all bugs. But I'm pretty sure they could reduce the probability of running into bugs by a few orders of magnitude.
Don't even get me started on how programming languages don't help you handle error conditions or timing problems even if you try.