You have an astounding dedication to your craft.
I have a piece of C code that I license to companies (it does multi-label classification of documents---mostly email) and I have very good test coverage and have been obsessive about its design and operation. Since it does a lot of low level C tricks for speed I wanted to be absolutely sure that it wouldn't crash, and it has to work on Windows (32 and 64), Solaris, HP/UX, AIX, Linux, ... The bottom line is that being obsessed about the stability of the code has meant that in the five years it's been shipping not a single client has reported a bug and I have never heard of the code crashing.
This actually turned out to be a problem for me, because I had a hard time getting some people to renew maintenance on the code because it never failed.
Maintenance would consist of lowering the multiplier of "crash" occurance. So your Program is always improving. I see little difference between this and the way hardware makers cripple lower end hardware
You can sell maintenance then. Slimy, i know. But business is business.
This last is then followed by
* You have to verify the compiler,
* You have to verify the hardware,
* You have to verify that there wasn't an error in loading the code,
* You have to use radiation-hardened hardware
* ...
and so on.
They miss the point!
Bugs in your code are way more likely than any of the other problems, and they matter.
I've generally given up, but at least it's nice to see the attitude here not being instantly shouted down.
As might have been predicted the bug that Raymond was talking about wasn't caused by the optimizer at all (http://esr.ibiblio.org/?p=1705#comment-248328).
It's depressing to think that when your code works, it's almost always your fault.
Obviously, this false, but until you are smart enough you'll never know when the compiler is wrong.
And they were right - my code had bugs in it.
So I recrafted my code and effectively, informally proved it to be correct. Then I sent it in again and got a formal acknowlegement that I had, indeed, found a bug.
Over the next 2 years I found 5 bugs in three different compilers, but in the first few cases I spent ages crafting my examples to prove the problem wasn't my code. Then it dawned on me, why not right the code to be correct in the first place, then I wouldn't have to re-write it when I found bugs that might be mine, and might be someone elses.
My productivity improved dramatically, and I was hooked.
I'm not disagreeing with your premise, but I find my attitude can be different depending on the scope of the project. For example, if I'm working on a smaller project, I find I can focus on the overall quality and strive for "no bugs." But on a larger project (often behind schedule and over-budget, most often not because of the dev team, directly), there are lots of edge cases that get ignored, at least during the first release cycle.
With Tarsnap, my incentives are perfectly aligned: Writing good code results in happy Tarsnap users, which results in more Tarsnap users.
I'm definitely glad you put out these bounties - you set a very good example for us all.