Just Try it or "is there a fly in your soup?"

by Pascal Rettig posted Jun 09, 2008

To badly paraphrase from memory the joke told during the credits of the classic Eddie Murpy comedy Coming to America (back before Eddie's live acting career became pretty darn irrelevant):

Customer : Waiter come taste my soup.
Waiter : Is there there a problem with the soup?
Customer : Just taste the soup.
Waiter : Is it too hot ? Is it too cold ?
Customer : Just taste the soup.
Waiter : Is there a fly in the soup ?
Customer : Just taste the soup.
Waiter : Ok, fine I'll taste the soup! Where's the Spoon?
Customer : Aha!

 This joke illulstrates the sort of rut that it's important to avoid as a Developer when dealing with complaints and Bug reports from clients and users. In an ideal world, any web-related user-reported* bug should always include at least the following info:

What url did happen at and what were you doing? When did it happen? What did you expect to have happen? What actually happened? What browser are you using? What account are you using? [ Also helpful: What "Ad Supported Toolbars" do you have installed? How many different P2P Clients have your children installed on your computer? ... ]

But 90% of the time the bug report consists of:

It didn't work. 

Playing the Jerk Programmer card isn't the best way to build repeat business. Sometimes, the right thing to do is just try the soup. Take what little information you are given and do your best to replicate the problem - provided you're not wasting hours of time -  and then gently prod the submitter for the additional information you need.

I've found that more often that I would like to admit, a quick attempt to replicate the problem myself will turn up the bug without too much back and forth. And everyone will be happier for it. Feel free to send over that detailed "Bug Report" form to the client for next time. They won't actually use it, but it will make you feel better.



*As an aside, I say user-reported because if your system is generating an exception you should already have all that information wrapped up in a nice package yourself - In our case using Rails' rescue_action_in_public lets us drop exception data into the Db and send an email with a stack trace directly to an administrator.