6 ms·

The assumption that asking for more information to recreate the bug is a lazy tactic to get out of the bug fix is also a terrible assumption and discredited the

The assumption that asking for more information to recreate the bug is a lazy tactic to get out of the bug fix is also a terrible assumption and discredited the opinion IMO. Often times asking for more information can speed things up and lead to a quicker resolution.

gitgud 6y ago
Yeah I thought that was really bad advice, especially for incomplete bug reports. There's literally no harm in asking for more information to fix a bug, except for your ego... A 5 minute phone call or direct message can save hours of hunting and frustration trying to replicate the bug...
c0nsumer 6y ago
Unfortunately, working in a big enterprise world, I've seen both sides of this. After a while it becomes somewhat obvious if someone is legitimately asking for more info, or if they are just punting the ticket down the queue. (The former is when you can tell they are becoming focused whereas the latter seems to be more general, swirling questions.)
- newshorts 6y ago
  True, having seen this as well, the motivation driving the dev does eventually become pretty transparent.
- bonestamp2 6y ago
  Agreed, although we (mostly) solved this a number of years ago. Our validation team has screen recording software running all the time. If they see an issue, they attach the video to the bug report. These videos dramatically improve everyone's ability to accurately report bugs and quickly resolve them.
- gshulegaard 6y ago
  I too have seen the case when a developer will ask for more information in order to game the process. While this is arguably (and I would agree) a failure of the process since it incentivizes undesirable behavior, you can quickly wind up in a situation where there is a large cadre of developers who will reflexively ask for detail. In this situation you often have good "measured" performance across the engineering org, but there tends to also be a large swath of tickets which find themselves in limbo. Some of these tickets can take months to resolve when a day or two of concentrated effort could have resolved it.
EsotericAlgo 6y ago
I suspect most developers have been on both sides of it. I've most often seen it as a delaying tactic where access/system bureaucracy prevents easy recreation. So generally dysfunctional enterprises.
stx 6y ago
In my experience sometimes this is true, sometimes it is not. In some cases when asking for more information it takes much longer. Some of the reasons: After asking the question I get a meeting schedules where design by committee happens. The story or bug your working on gets completely redesigned. Sometimes in an illogical way. Requiring more questions. When working remote, like most of us right now, now I will end up waiting for a long time to get a response. I then must start some other story/task/bug. Trying to context switch multiple complex tasks at some point your productivity slows down. I have also received criticism for asking when I could figure it out myself even when figuring it out may have taken hours more time then just asking a yes/no question.
norenh 6y ago
I have worked on both sides of this in the enterprise world (as a support agent in the middle of dev team, as a end user and as a developer on the receiving end) and it is never simple. A bug report takes time to make and many times it might take time to reproduce or narrow down to a simple test case. A developer should of course get the information needed to fix a issue, but very often (s)he can find the issue with very little detective work if they know the product. The problem I've seen is that you have a fundamentally broken system where: 1. The devs don't really know the product in the sense that they do not use it. They have very little experience how it actually is used or the workflows and might not have good overview of the code base. 2. The support agents, if they exist, have little clue of either development or the product and just as a filter to remove the absolute majority of known issues but at the same time mess up the communication between end-user and devs 3. The end user have neither time or experience to test or report issues so you get very bad reports that vary wildly. When working as a support agent I have spent a lot of my time acting as a filter to stop making the end-users go mad with all the requests from the devs and preventing the devs from being flooded with crap reports (of course, some always slip through). That means a lot of time spent on reproducing and testing (and sometimes pointing out where the bug is in the code, even suggesting patches). But very few organisations pay for that knowledge and very few allow agents to muck around for a day with a tricky issue to make sure the devs can fix it without a major hassle. It is very easy to ask for more information as a dev, and very often it is needed, but a lot of the time it is just pushing the cost to the end-user when a minimal amount of detective work (or even a single quick test) would do the same and save everyone a lot of hassle. I would argue that in a lot of time when we, as devs, ask for more information we do it to push the issue into the future and to save ourself a minuscule of work now, not to have a quicker resolution.
- addicted44 6y ago
  Assuming the reporter is internal, you don't need them to go ahead and type out everything. A quick call with a screen share is all that's needed. Not even reaching out (again, assuming they are internal...if they are external then there are many other considerations) is just not smart IMO.
jedimastert 6y ago
Also, asking for more information lets you work on something else with more actionable feedback while they do so
- dgb23 6y ago
  I agree with this. If you are generally swamped with work, you need to do triage and possibly delegate work. This isn't perfect behavior. But in some situations the perfect solution isn't feasible.
labcomputer 6y ago
Sure, it depends on the context. But I've seen many examples where the reportee is asking for information that's already in the bug report, or can be easily inferred from the report.
halgir 6y ago
I know this can be nuanced, as pointed out in other replies. But as a product manager, I admit to having used this as a form of triage. People have told me they don't have time to write a proper bug report. I tell them if it's not important enough for you to spend five minutes reporting, it's not important enough for a developer to spend five hours fixing. I of course don't respond to everything as black and white as this, and I'm not expecting them to do the kind of troubleshooting that me or a developer could do much quicker.

gitgud 6y ago

Yeah I thought that was really bad advice, especially for incomplete bug reports. There's literally no harm in asking for more information to fix a bug, except for your ego... A 5 minute phone call or direct message can save hours of hunting and frustration trying to replicate the bug...

c0nsumer 6y ago

Unfortunately, working in a big enterprise world, I've seen both sides of this. After a while it becomes somewhat obvious if someone is legitimately asking for more info, or if they are just punting the ticket down the queue. (The former is when you can tell they are becoming focused whereas the latter seems to be more general, swirling questions.)

newshorts 6y ago
True, having seen this as well, the motivation driving the dev does eventually become pretty transparent.
bonestamp2 6y ago
Agreed, although we (mostly) solved this a number of years ago. Our validation team has screen recording software running all the time. If they see an issue, they attach the video to the bug report. These videos dramatically improve everyone's ability to accurately report bugs and quickly resolve them.
gshulegaard 6y ago
I too have seen the case when a developer will ask for more information in order to game the process. While this is arguably (and I would agree) a failure of the process since it incentivizes undesirable behavior, you can quickly wind up in a situation where there is a large cadre of developers who will reflexively ask for detail. In this situation you often have good "measured" performance across the engineering org, but there tends to also be a large swath of tickets which find themselves in limbo. Some of these tickets can take months to resolve when a day or two of concentrated effort could have resolved it.

EsotericAlgo 6y ago

I suspect most developers have been on both sides of it. I've most often seen it as a delaying tactic where access/system bureaucracy prevents easy recreation. So generally dysfunctional enterprises.

stx 6y ago

In my experience sometimes this is true, sometimes it is not. In some cases when asking for more information it takes much longer. Some of the reasons: After asking the question I get a meeting schedules where design by committee happens. The story or bug your working on gets completely redesigned. Sometimes in an illogical way. Requiring more questions. When working remote, like most of us right now, now I will end up waiting for a long time to get a response. I then must start some other story/task/bug. Trying to context switch multiple complex tasks at some point your productivity slows down. I have also received criticism for asking when I could figure it out myself even when figuring it out may have taken hours more time then just asking a yes/no question.

norenh 6y ago

I have worked on both sides of this in the enterprise world (as a support agent in the middle of dev team, as a end user and as a developer on the receiving end) and it is never simple. A bug report takes time to make and many times it might take time to reproduce or narrow down to a simple test case. A developer should of course get the information needed to fix a issue, but very often (s)he can find the issue with very little detective work if they know the product. The problem I've seen is that you have a fundamentally broken system where: 1. The devs don't really know the product in the sense that they do not use it. They have very little experience how it actually is used or the workflows and might not have good overview of the code base. 2. The support agents, if they exist, have little clue of either development or the product and just as a filter to remove the absolute majority of known issues but at the same time mess up the communication between end-user and devs 3. The end user have neither time or experience to test or report issues so you get very bad reports that vary wildly. When working as a support agent I have spent a lot of my time acting as a filter to stop making the end-users go mad with all the requests from the devs and preventing the devs from being flooded with crap reports (of course, some always slip through). That means a lot of time spent on reproducing and testing (and sometimes pointing out where the bug is in the code, even suggesting patches). But very few organisations pay for that knowledge and very few allow agents to muck around for a day with a tricky issue to make sure the devs can fix it without a major hassle. It is very easy to ask for more information as a dev, and very often it is needed, but a lot of the time it is just pushing the cost to the end-user when a minimal amount of detective work (or even a single quick test) would do the same and save everyone a lot of hassle. I would argue that in a lot of time when we, as devs, ask for more information we do it to push the issue into the future and to save ourself a minuscule of work now, not to have a quicker resolution.

addicted44 6y ago
Assuming the reporter is internal, you don't need them to go ahead and type out everything. A quick call with a screen share is all that's needed. Not even reaching out (again, assuming they are internal...if they are external then there are many other considerations) is just not smart IMO.

jedimastert 6y ago

Also, asking for more information lets you work on something else with more actionable feedback while they do so

dgb23 6y ago
I agree with this. If you are generally swamped with work, you need to do triage and possibly delegate work. This isn't perfect behavior. But in some situations the perfect solution isn't feasible.

labcomputer 6y ago

Sure, it depends on the context. But I've seen many examples where the reportee is asking for information that's already in the bug report, or can be easily inferred from the report.

halgir 6y ago

I know this can be nuanced, as pointed out in other replies. But as a product manager, I admit to having used this as a form of triage. People have told me they don't have time to write a proper bug report. I tell them if it's not important enough for you to spend five minutes reporting, it's not important enough for a developer to spend five hours fixing. I of course don't respond to everything as black and white as this, and I'm not expecting them to do the kind of troubleshooting that me or a developer could do much quicker.