2 ms·

For customer-, client-, partner-, vendor-generated complaints, I also operate on the "always assume the bug is in our code" philosophy. You don't want to go bac

For customer-, client-, partner-, vendor-generated complaints, I also operate on the "always assume the bug is in our code" philosophy. You don't want to go back to a customer (customer, client, partner, vendor) and tell them that it's _their_ problem until you have sufficiently ruled out evidence that it was _your_ problem. In your case above, however, I would have spent a couple of days--max--before going back to the partner and saying "Hey, we've noticed this bug, and we're still investigating things on our end, but we're reasonably confident it's not something on our end. Can you take a look?" This would have saved you months, but also demonstrated to the partner that you've done (and are doing) due diligence to investigate the problem. But for 99% of interactions, you want to assume you're the one who screwed up. It's safer and it's better customer support. A similar rule to this is to remove the phrase "it works for me" from your vocabulary. The client wouldn't be complaining about it if it worked for them! So you need to rule out a bug before you go back and say "Hey, actually, you're the one who screwed up." I've found that maybe only 50% of the time is it client error, and so I always operate under the condition that the customer was right until I can prove that they weren't.

Jtsummers 5y ago
I agree, and we'd already done that (short investigation on our end). We just hadn't fully isolated the bug, which we ended up doing after a few months once we had discovered more about the failure pattern to direct our attention to one key area of the hardware system. This let us write a single program that reliably produced the failures. But if we'd let the hardware team know early on, they may have been able to put a few days in to investigate themselves instead of waiting for us to provide them with what they should have already known (it revealed that their design and testing was grossly flawed and incomplete).

Jtsummers 5y ago

I agree, and we'd already done that (short investigation on our end). We just hadn't fully isolated the bug, which we ended up doing after a few months once we had discovered more about the failure pattern to direct our attention to one key area of the hardware system. This let us write a single program that reliably produced the failures. But if we'd let the hardware team know early on, they may have been able to put a few days in to investigate themselves instead of waiting for us to provide them with what they should have already known (it revealed that their design and testing was grossly flawed and incomplete).