Except step 5 needs two variants, then: "Oh, I see why it happens" and "Oh, I see that it doesn't, so let's find a way to communicate better with the user".

There are a lot of ways that things can go, but starting out with the disposition that either the bug report is wrong or the other machine is somehow made of worse silicon than our own, is rarely helpful.

However, investigating every bug report while a worthy cause is something not practical for most shops, especially when the underlying cause for these 'only sometimes and only on my machine' issues is some bizarre bug in some underlying dependency or even windows.

Now fixing these issues can often lead to really lean mean software that flies, but if you're in the all too typical situation of overambitious deadlines then you're already in triage mode and long hard fixes are just about the bottom of the pile

> starting out with the disposition [...] is rarely helpful.

Of course, I fully agree. And yet I have witnessed enough developers stating the first stage almost verbatim as a response to a complaint that I grew really quite fond of the link.

It is, actually, quite useful in that regard - it allows you to point out the absurdity of the statement in a humoristic way.

That, and it wouldn't be a good parody of the Kübler-Ross model if it didn't start with Denial :-)

Agreed. The direction I was going is this: If there's a bug report, then there is a problem. The problem might be the bug that was reported, or it might be that you surprised the user/tester in a way that they perceived as being a bug. Obviously something needs to be improved, even if it's just communication with the user, rather than changing the behavior of the program.