Podcast #128: We chat with Kent C Dodds about why he loves React and discuss what life was like in the dark days before Git. Listen now.
674

Tell them this is only an amateurish name for the Root Cause field used by professionals (when issue tracker does not have dedicated field, one can use comments for that). Search the web for something like software bug root cause analysis, there are plenty of resources to justify this reasoning 1, 2, 3, 4, .... ...a root cause for a defect is not always ...


273

Another probable result for such a policy is that people won't report bug if they think they may be the "person to blame", so it will actually reduce the number of bug reported by the team.


141

The main argument I would use against it is to ask what problem he's trying to solve. There are almost certainly better ways of solving the same problem. For one thing, is there really only ever one person to blame? If there is, you're doing something else wrong. A good process takes a piece of work through an analyst, a programmer, a reviewer and a tester ...


105

What's a decent way of responding? Thank them for the report. Reassure them you are listening to their feedback. What should I keep in mind? That you can't please everyone and that some people don't seem capable of not being rude. What mindset should I have? You don't have to follow through on all the points that were brought up. It is your app ...


79

There are at least three problems with that field. The first one is that blaming people isn't good for morale. Ok. But maybe he doesn't care about morale and wants to fire bad developers. Hard to argue against. The second one is that getting that field right is going to be hard and a pretty big time sink. It's more complex than just finding out who wrote ...


73

Imagine if Stack Overflow had a guideline: instead of asking one question, you come and ask, in the same question, whatever comes into your mind, all your issues you had for the last two weeks. What would upvote and downvote mean? What would be the titles of the questions? How to accept the best answer? How to tag the question? Bug tracking system is done ...


68

The root cause for a fielded defect is never a single person. Perfectly conscientious people will make errors, and a process that expects them to be infallible is unreasonable. If you are not verifying changes to production systems before deployment, either manually or through automated testing, then bugs are inevitable. Wrong: Bob forget to check ...


58

To a software team, a bug is a software problem that needs to be fixed. Not all software problems need to be fixed. Updating software is expensive. Blizzard is telling you that your problem is an edge case. In other words, the edge case problem you discovered is not necessarily something they tested for or otherwise care to account for. Fixing the ...


54

Change "Person to blame" to "Person to praise" The main person to fix the bugs gets their name on it.


51

In my opinion, it's a good practice, assuming your users have read access to your bug database. There are lots of times when people are waiting on a certain bug to be fixed in order to decide when to upgrade. I think what's frowned upon is only citing the bug id and nothing else. You should always also supply a description that is understandable without ...


49

Simple answer. The "Blame" field will be used for nothing more than scapegoating and fingerpointing, morale will plummet, team trust will be destroyed and everyone will be trying to find ways to prove that something is not their fault instead of fixing it. People will also be more inclined to keep quiet about bugs instead of reporting them, because they ...


47

If you have this problem where users are assigning ever-higher priority bugs then the only realistic solution is a triage mechanism. All bugs get reported with whatever priority they like, but some poor manager will have to go through every newly reported bug and reset its priority to a sensible level. After a while your users will either get the message, ...


45

If you're up for a little civil disobedience, get the team to agree to put a list of all the developers in that field for each bug. If that won't fit, write "I'm Spartacus!" instead. The point, of course, is that you're all responsible for all the bugs, and you're not happy about having to point out the individual who created any one bug. Another option: ...


42

I asked some colleagues about what this may be happening, and they mentioned that if a bug doesn't haven't that level of priority it is very rare that the Bug gets developer attention, which indeed makes sense Actually, if you ask me it does not. The more (used) levels of priority, the more information you have. If you effectively only have one ...


32

I once had a boss implement a system very similar to this, and although it wasn't programming (it was print design for a daily newspaper) the concept and appropriate response are the same. What she did was instead of adding a 'person to blame' field on our paperwork she gave each of the designers a set of colored stickers. Each designer got a different ...


27

In my opinion, what's more important is using the bug to establish meaningful on going contact with the user. Writing and understanding bug reports is a skill, and my advice would to be to make it as easy as possible for the user to make first contact, then progressively make their feedback of more value as needed. For example, just get the user's email, ...


24

Here is the mindset that I have asked my developers to follow: 1) Imagine you are the doctor in the emergency room treating the obstinate patient. The doctor is professional in every way and helps the patient even if the patient is yelling to not help. 2) Imagine that the person who is rude just had something terrible happen to them and they are terribly ...


22

This kind of reminds me of the cat in the microwave, specifically the case of Mrs. Smith in 1983. The point is, you expect the product to work in such a way. Mostly because a number of similar products work like that, i.e. if you minimize them for hours and then open them up, they work (although the opposite is not as uncommon as you might think). Mrs. ...


20

This sounds a lot like when Scott Adams pointed out the failed wisdom of a Bug Bounty when the Pointy Haired Boss in Dilbert. Wally announced he was going to go and 'write him a new Mini Van". Dilbert comic strip for 11/13/1995 from the official Dilbert comic strips archive. I recall once when Snow Skiing that someone pointed out that 'not falling" was ...


20

It will wind up punishing his most prolific programmer. Odds are, one or two people might be the best employees who have worked on the most projects. If you have, in a 10-person department, one coder who is just a fountain of output and he's written 60% of the interface code, then 60% of the bugs will be in his code. Explain that this system would make it ...


19

Maybe you should look at it as "Who is in the best position to fix the bug?" A part of me also feels, you broke it, you fix it. There should be some accountability. I don't agree with keeping some sort of score. Some people create more bugs because they work on more complex parts of the code. If lines of code isn't a useful metric, I doubt bugs per lines of ...


19

It is strange that no one mentioned this before: Adding such a functionality to the bug tracker would motivate employees to try to game the system. This is a common problem for approaches like what the question presented, among other similar ideas (paying by number of code lines, paying by number of bugs). This will encourage many to focus on getting a good ...


19

The closest you get to a bug-free application, the more expensive it gets. It's like targeting 100% code coverage: you spend the same amount of time and money getting from 0% to 95%, from 95% to 99% and from 99% to 99.9%. Do you need this extra 0.1% of code coverage or quality? Probably yes, if you're working on a software product which controls the cooling ...


18

Your actual question was about how to change the culture before you leave the company, by convincing your boss that adding a person to blame field for bug reports is a bad idea. But of course changing the culture requires him to really understand why this is a bad idea. This is a tall order. Besides the issue of saving face after changing his mind, there ...


16

The most effective way to get users to write decent and useful bug reports is to let them see their reports online... [System] Thanks for reporting, you can find status of your request here: ... ...along with the evaluation and comments from assigned engineer... [Engineer] Request rejected, for the following details are missing: ... ...with an option to ...


15

There is nothing wrong with submitting duplicate bug reports. If your search for similar bugs did not turn up a duplicate, sending a bug report is the best thing you can do. The worst thing that could happen is that the developers working on the product closes your report as a duplicate. This is much better than letting a genuine problem go unnoticed. You ...


14

It is, as said in the quoted comment... unfriendly. Unfriendly with yourself Imagine the following scenario. You are viewing the logs in source control. You are wondering what a commit changed. Instead of explaining it in plain English, it tells you: Solved #1307 You run the bug tracking system, hoping to have something helpful. Bug #1307 is reported ...


14

People don't go to work intent on making mistakes, and any strategy set in place, to specifically attach blame for what may or may not have been human error is ridiculous - not to mention extremely unprofessional. At the very least, a "responsible party" assigned to take charge and "fix" the issue, or come up with a plan to track and/or prevent similar ...


14

DISCLAIMER: I have not yet had experience with user-reported bug priority shenanigans. I know the question asks for this, but it might help having the perspective of an outsider. Your problem is not that you have too many high-priority bugs. Your problem is that you have too many people who have direct control over bug priority. If every user can directly ...


Only top voted, non community-wiki answers of a minimum length are eligible