4 ms·
I like the analogy. I'm trying to get people in my organization to understand that it's not a bug when a feature works as specified in the app requirements. Eit
by bpyne 6y ago
I like the analogy. I'm trying to get people in my organization to understand that it's not a bug when a feature works as specified in the app requirements. Either the requirement wasn't specified well or a change of circumstances requires it to work differently. In either case, it's a request for modification not a bug. Your analogy should help me explain the difference.
- tuwtuwtuwtuw 6y ago> I'm trying to get people in my organization to understand that it's not a bug when a feature works as specified in the app requirements Oh no.... You are wasting yours and theirs time. This is such a developer thing to do.
- bpyne 6y agoPlease see my comment to allanniehuis.
- allannienhuis 6y agoThe 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 agothere'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 agoRight, 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 agoWhether 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 agoIt 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.
- coelh0 6y agoDon't confuse the waiter with the customer. If the waiter gets the request wrong from the customer, it's still a bug. Even if the kitchen does exactly what was in the waiter request. It's a team effort.
- bpyne 6y agoPlease see my comment to allannienhuis.