4 ms·

The user doesn't care whether the bug is in the requirements or if it's in the code. They just know that it's not working for them, and want it changed. Argui

The user doesn't care whether the bug is in the requirements or if it's in the code. They just know that it's not working for them, and want it changed. Arguing that it's not a bug seems like saying 'not my problem' to everyone else. I expect different companies have different cultures around assigning blame that might make saying 'not my fault' important, but I'm pretty sure that customers/users don't care one bit about that.

jiveturkey 6y ago
there's a -- critical -- feedback loop problem that you're ignoring. sure, you might work on it with the same priority regardless of characterization. but if it's properly classified as an error in specification, that is extremely valuable information for process improvement.
- tuwtuwtuwtuw 6y ago
  > but if it's properly classified as an error in specification, that is extremely valuable information for process improvement. For a few companies, sure. The chance that he's working on one of those is zero (based on what he has written so far).
ahungry 6y ago
Right, to the customer it doesn't matter (just like to the developer it doesn't need to matter either - it just means the work needs to be performed). However, it matters greatly to other observers - if one person or team is highly out of the norm for rate of bugs, it might be indicative of other problems that need to be worked on (lack of testing, peer review, tasks being assigned beyond the working abilities etc.). Just like the restaurant analogy - the expectation is that bugs shouldn't be happening to begin with, and when they do, it should be "our fault" to remedy them.
bpyne 6y ago
Whether it's a bug or a modification to requirements I'm still the one who works on it. So "not my problem" doesn't exist in my situation. The distinction matters very much when it comes to prioritizing my work. I'm 100% time on projects and jump from one to the next with no pause between. I'm also the only developer who supports the apps I built. Bugs usually jump to the top of the queue. Management puts a lower priority on requests. In order to not hurt my current "customer", I need to make sure past ones don't try gaming the system by declaring bugs when they're not.
- tuwtuwtuwtuw 6y ago
  It is very common for companies to forget how to properly prioritize between bugs and features. Trying to reinforce this by trying to teach them how to correctly (according to person on internet) classify bugs or features still sounds like a complete a waste of time.

jiveturkey 6y ago

there's a -- critical -- feedback loop problem that you're ignoring. sure, you might work on it with the same priority regardless of characterization. but if it's properly classified as an error in specification, that is extremely valuable information for process improvement.

tuwtuwtuwtuw 6y ago
> but if it's properly classified as an error in specification, that is extremely valuable information for process improvement. For a few companies, sure. The chance that he's working on one of those is zero (based on what he has written so far).

ahungry 6y ago

Right, to the customer it doesn't matter (just like to the developer it doesn't need to matter either - it just means the work needs to be performed). However, it matters greatly to other observers - if one person or team is highly out of the norm for rate of bugs, it might be indicative of other problems that need to be worked on (lack of testing, peer review, tasks being assigned beyond the working abilities etc.). Just like the restaurant analogy - the expectation is that bugs shouldn't be happening to begin with, and when they do, it should be "our fault" to remedy them.

bpyne 6y ago

Whether it's a bug or a modification to requirements I'm still the one who works on it. So "not my problem" doesn't exist in my situation. The distinction matters very much when it comes to prioritizing my work. I'm 100% time on projects and jump from one to the next with no pause between. I'm also the only developer who supports the apps I built. Bugs usually jump to the top of the queue. Management puts a lower priority on requests. In order to not hurt my current "customer", I need to make sure past ones don't try gaming the system by declaring bugs when they're not.

tuwtuwtuwtuw 6y ago
It is very common for companies to forget how to properly prioritize between bugs and features. Trying to reinforce this by trying to teach them how to correctly (according to person on internet) classify bugs or features still sounds like a complete a waste of time.