Developer: “That Works Fine on MY Computer…”
The inconsistently repeatable bug is the Product Manager’s nemesis. One of the worst things I can hear from a developer is the phrase “Gee, that works fine for me.” Usually followed by “We’ll continue to look into that.” Which is code for “I’m deleting this bug report from my queue until someone screams louder or demos it for me.”
As a PM, you don’t have time to run down every bug that a customer reports (if you do you’re spending too much time in the tactical and not enough on strategic). You must delegate and trust the development team to knock the bug out. What can you do to prevent these bugs from falling off the list? Here are a few tools:
- If you use a tool like Salesforce or FeaturePlan, you can track the volume of feature request or bug reports incoming. If the same non-repeatable bug shows up 50 times in the customer pool and the developers can’t replicate it, maybe it’s something dumb. Like, say, your program is now incompatible with a certain version of Outlook (which your customers and the rest of the World uses) while your developers use pine. That’s an extreme example of course, nothing like that has ever happened to me…
- Help Development by classifying bugs on severity and frequency. It’s always a goal to ship with zero P1’s, but you may choose to let one go if it’s a 1 in 1,000,000 kind of bug (unless you work in medical).
- Sometimes it makes sense to hook the end user up directly with the developer. This is a last-resort option for me; I hate for my end users to know anything about my developers because they try to circumvent the process and go direct to the developer the next time.
What else do you do for non-repeatable bugs?
2 Responses to “Developer: “That Works Fine on MY Computer…””
1 Derek Morrison 29 April 2007 @ 9:50 am
I know just how you feel - I worked in a company a few years ago where the most common saying from the engineering team was “it was alright when I had it!” Scrum (Agile management frame work) threatens to tackle this issue - the technical team: testers, developers, DBAs etc…become the “TEAM” and meet on a daily basis for 10 - 20 minutes max! they then have to be accountable to the product owner for any issues that they have agreed to work on. Emerging issues are put on a list (product backlog) and are tackled at the next iteration of development. See for more..
http://www.kw-agiledevelopment.blogspot.com/
2 Bruce McCarthy 8 May 2007 @ 6:54 pm
First, you need a bug tracking system so you have a database of all the bugs. Most people have this, but some put it completely in the hands of the developers. While developers can tentatively classify a bug as “unreproducable” or “no plan to fix, only QA can actually confirm that by closing the bug. And, as you say, as the representative of the customer, the product manager has final say on the priority and severity of a bug.
We also have a weekly (and sometimes daily near the end of a release) bug triage session with the product managers, developers and QA moderated by the program manager. Program managers usually make good referees in these situations by maintaining a reasonable tone and balancing the concerns of all involved and extracting dates from people. This open process makes it hard for the developers to simply “look into it” indefinitely.
Leave a Reply