My boss decided to add a "person to blame" field to every bug report. How can I convince him that it's a bad idea?
In one of the latest "WTF" moves, my boss decided that adding a "Person To Blame" field to our bug tracking template will increase accountability (although we already have a way of tying bugs to features/stories). My arguments that this will decrease morale, increase finger-pointing and would not account for missing/misunderstood features reported as bug have gone unheard.
What are some other strong arguments against this practice that I can use? Is there any writing on this topic that I can share with the team and the boss?
Hey guys, I'm the "boss" who introduced the WTF field. Here's why I added a "Peson to Blame" field to our bug tracking system: http://news.ycombinator.com/item?id=4179298
"Could I have named it something more politically correct so feeling doesn't get hurt? Sure. But what's the fun in that? The point was to bring awareness to the number of production bugs after each release so why not throw in a small dose of public shaming for good measure? And to be clear, the purpose of the field, and ultimately the purpose of the metric, is not to pinpoint the cause of the bug. Shit happens and we have better things to do. The ultimate purpose of the metric is a reminder for each developer to be better everyday." --- I think all of these "reasons" are inherently wrong.
In case of escalation, elaborate in each and every issue what lead to the issue. Elaborate on the most basic groundings in code, project history and project management and elaborate on why the person in the field is not solely to blame or why there is none selected.
@Jason instead of inventing Jira fields, **consider hiring back one or two testers**. BTW in your case having root cause field (no matter how you name it) looks low importance to me because you already groked connection between absence of testers and _increase in production bugs_.
@Jason The bug is in the code, not in a developer. You must be one of those people that thinks that code reviews are for reviewing developers, not code.
Any book on systematic thinking spends most of the book volume on trying to show how blaming people is inferior to a systematic approach. I can't suggest you a book, as the book I've read is not available in your language! You can find a very short book and give him as a gift!
@Jason There is a reason there is this outpouring of support for your developers side, and the reason they posted it here. Perhaps you should reconsider if your **FUN** idea is really worth the stress you just added to your team.
**"Could I have named the field [differently], so that feelings don't get hurt? Sure. But what's the fun in that?"** -- this says a lot about how Jason wants to run his team.
Your boss is the "person to blame", fill his name in always and see how he likes it ;)
So it's now been a couple of months. How has this evovled? What do you think about this now? What does your boss think?
@poolie He has his fun hurting people... I don't think that it has sense to solve any problems with a practicing sadist apart from the dialogue between doctor and patient behind well-holstered doors. He won't understand any logic.
I'm more curious if the OP got fired for "outing" his boss? At several companies I've worked for, if your boss found out you posted something like this, you'd be shown the door immediately.
@DannyVarod seeing the number of companies that do exactly that, use code reviews as performance reviews of the coders...
@jwenting code reviews can help monitor and improve quality, not performance, however, if the review is misused, then the author of the code will not help find bugs during the review, thus the review will not be efficient. Also, you should be reviewing the design and the tests.
@DannyVarod we both know that, doesn't change reality though... And yes, it tends to make the reviews useless for finding bugs or improvement points as it bogs down into trying to juggle for position in the team (and for some people trying to not become scapegoats and lose their jobs due to problems they didn't cause but failed to solve).
"We anticipated the increase in production bugs when we moved away from having a dedicated QA team. But, as we get closer to having a true continuous deployment system in place, we need to start treating production bugs as the exception rather than the rule." -- from Y Combinator article. I wouldn't even know where to explain to Boss how wrong everything about that statement is. But I don't have to; I'd much rather convince the developers better jobs lie everywhere. underdog.io, offerletter.io, step.com, https://nytm.org/marketplace/jobs, etc....
If code reviews are being performed, then the code after the review belongs jointly to the review team. If it has bugs then they are all equally responsible.
I'm curious, what was the outcome with this? Did your manager go ahead with the finger pointing exercise or did you manage to talk him out of it? If the former, what was the effect of it?
Easy solution. 1. The boss is the default "person to blame" for each new ticket. 2. The field can be reassigned only one ticket at a time. 3. The field can only be reassigned by the current assignee. 4. The reassignment should always be accompanied by a comment at least 100 characters long (comments identical or similar to comments on other tickets are not allowed, and no "gibberish" allowed either).
@Jason It's been 5 years since this was posted, so if I could ask for posterity's sake, was this a real thing or were you guys playing a joke? I ask because jokes like this are fairly common (**"_Leeroy Jenkins_!"** being the easy example), and while your typing's really not too bad by itself, you somehow typo'd the title of the article you linked, **"_Why I added a "Peson to Blame" field to our bug tracking system_"**. Anyway, long question short - was this for real?
This question is off-topic for SoftwareEngineering.SE. It belongs on TheWorkplace.SE!
When I spot a bug in our code, and I do a `git blame` to see the commit in which the bug was introduced, `git` shows me who it was who committed that bug. But honestly, I'm rarely interested in that. Most of the time, I'm interested in what was involved in that commit. I want to know the context of the bug, so I can understand what was the idea behind that commit. Who committed that bug to our code is less important than why they committed it.
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).
...a root cause for a defect is not always a single developer (which is the main point of this field)...
That's exactly why "root cause" is professional while "person to blame" is amateurish. Personal accountability is great, but there are cases when it simply lays "outside" of the dev team.
Tell your boss when there is a single developer to blame, root cause field will definitely cover that ("coding mistake made by Bob in commit 1234, missed by Jim in review 567"). The point of using the term root cause is to cover cases like that, along with cases that go out of the scope of the dev team.
For example, if the bug has been caused by faulty hardware (with the person to blame being someone outside of the team who purchased and tested it), the root cause field allows for covering that, while "single developer to blame" would simply break the issue tracking flow.
The same applies to other bugs caused by someone outside of the dev team - tester errors, requirements change, and management decisions. Say, if management decides to skip investing in disaster recovery hardware, "blaming a single developer" for an electricity outage in the datacenter would just not make sense.
This is a good point. However, a root cause for a defect is not always a single developer (which is the main point of this field). As a result, identifying a single developer responsible for a defect does more harm than good, IMO.
@MK_Dev yes that's the point that makes "single developer" idea, well, pointless. When there's "single developer" to blame, root cause covers that, but opposite isn't true: there are root causes that don't fall on single dev. That's why RCA is professional's choice, it is simply more powerful than your boss suggestion. I'll think about how to update answer to make that clear
I assume the "single developer" idea is also to have an easily structured data point that will allow a report to be run at the end of the month. A general root cause field would be too nebulous to get an accurate "who to fire this month" readout.
+1 for redirecting the boss's idea into something more productive (always easier to win a battle that way)
"Root Cause" also covers (hopefully the majority!) of cases where no single person is to blame, things like "vendor software failure", "API documentation error", "Higher Volume Than Expected".
Great. Even your example for a single responsible person features two people, perfectly illustrating the stupidity of the exercise.
Don't forget that "contributing causes" would also be useful since they are often easier to do something about. For example if "root cause" was "coding mistake in commit 5678" and "contributing cause" was "commit 5678 was not reviewed because requirements came too late", than you can't avoid all coding mistakes, but you can be stricter about delaying delivery next time requirements are delayed.
I think RCA sounds good, but I'd be careful about putting people's names in. I doubt that would be good for morale, and if someone is careless often you won't need a RCA to know who the problem is.
Having a many-to-many relationship between infractions and root causes would be more reportable. Each root cause could then be associated with a single employee, accident, etc. In a well-designed interface, it would be almost as fast and easy for the user to enter each cause and have it auto-lookup employees and other possible causes and allow you to easily associate them or add new causes as needed, similar to how tagging works in many apps these days, rather than just having them enter a list of things just stored in a single field.
The new field is basically a "notes from the time when the incident was still fresh in our heads" field. Evaluation of procedures can only happen with some experience, and a bug reporting database that has enough data to make statistically significant statements, at which point incidents might be a few months away. This information is vital, even if it is by nature unstructured and must be manually compiled for a report; a name whom blame was assigned to back then is not helpful, because you no longer know whether that was a final verdict or an intermediate result (even if that meant anything)
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.
Well, the boss will be happy! There'll be fewer bug reports, and therefore, the quality _must_ have gone up.
The boss is probably on performance related pay and one key performance indicator is the number of bugs reported. Hopefully he/she will share out his bonus to the development team at the end of the year.
From experience, this is not a "probable" result, it's 100% absolutely certain that this will happen, because developers are smart people. What you will also see is a massive increase time spent arguing violently with testers that their "bugs" aren't bugs.
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 before it gets to production. If you're not doing all of these stages, maybe that's the solution to the problem your boss is trying to solve. If you are then which one is to blame? It might be none of them, it could be legacy code that's to blame.
It's no good having people back-biting and pointing fingers, trying to avoid a black mark which won't go away once it's set. It solves nothing. Very few people are maliciously negligent. You need to do a proper retrospective, see what went wrong and what you can do to make sure it doesn't go wrong again.
From that you will clearly see if one person is regularly at fault and that may be a different problem to deal with.
The trick to stopping a manager set on creating accountability is to offer it freely, but in a way that actually makes sense to you.
A really good process avoids the analyst and the programmer to be two different persons - my experiences with analysts who cannot program and programmers who cannot analyse were really bad. Nevertheless, +1 for your answer.
@DocBrown well my experiences with analyst and the programmer to be two different persons have been rather positive so far. Though in my case it was rather _analysts who can understand program logic and programmers who can participate in analysis_ :)
@gnat: IMHO having the analyst beeing one of the programmers in your team can improve your development speed and quality by an order of magnitude.
This book will help you find the words to stand your ground http://www.amazon.com/The-Power-Positive-No-Relationship/dp/0553384260/ref=sr_1_2?ie=UTF8&;qid=1340917410&sr=8-2&keywords=Author+Ury
In safety critical systems we moved away from "the process means no individual can ever be to blame" at the turn of the century. It is possible to have a single person do something so bad and cover it up so well that they are to blame. It is however, very rare. The process can only protect against human error, it cannot protect against intent.
@mattnz: Oh, I didn't say never. I said that **few** people are maliciously negligent and that retrospectives will show those up as surely as they show up process problems.
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 the bad code. And any potentially information that is hard to figure out can be sandbagged/cheated on. But maybe he's prepared to pay that cost and audit the information. Fine.
The more fundamental issue is that this field is not going to be a good metric to take action on. Sure, he'll have a nice ranking of whose code causes the most defects. But guess who'll be on top of that list? Probably the company founder, or maybe a top developer who has a very low defect rate but is so productive he writes a disproportionate portion of the code. So he'll either end up firing his best developer, or have him slow down so much he's not his best developer any more. And they guy who writes a line of code a month - preferably comments - will probably get rewarded for his low defect numbers.
Yet another software metric failure.
I'm surprised nobody else has mentioned the fact that analyzing the history of an error in attempts to assign blame is going to be a huge time sink. If no other arguments bite, that should.
So you guys fix errors without trying to find out the history and root cause? At that point you're fixing symptoms, and possibly ignoring legitimate core problems. If it actually is a problem with a person, it helps to know why the person made the mistake so it can be corrected. If it's faulty hardware, that can be swapped for something more stable.
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.
Bob forget to check input and the program crashed dividing by zero.
Code vulnerable to a divide by zero error was not detected before deployment. New test cases have been added to verify proper handling of invalid input. Code was corrected and all new test cases are passing.
Even better: Coding guidelines/standards and code review checklists updated to avoid this happening again.
So what if bugs are inevitable? What's wrong with blaming someone for them? I think your 'Wrong:' option is more clear than your 'Right:' option. The wrong one is really simple. The 'Right:' one is wordy.
Change "Person to blame" to "Person to praise"
The main person to fix the bugs gets their name on it.
I don't think this answers the question. It's a good sentiment, but doesn't provide arguments against such a field.
Plus, you know one guy will introduce hundreds of bugs "accidentally" then fix them all, hoping some idiot manager will be dumb enough to think he's the best bug-fixer...
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 don't want a colleague to get into trouble. It's completely counter productive.
What's more important, victimising somebody for making an honest mistake, or getting the problem fixed as quickly as possible?
Your boss seems to think bugs are a sign of laziness or sloppiness. They're not. They're a fact of life. How many patches does Microsoft push out in a year?
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: play along. Don't do anything in particular -- just do good work and fill in the field as accurately as you can for a few months. Then explain to the boss that assigning blame for each bug makes everyone on the team unhappy and uncomfortable. Tell him that you all feel that there's little correlation between bugs created and anything else (skill, effort, sanity). (It'll help if you can run some numbers that show that there really isn't a correlation.)
Gandhian Civil Disobedience: Put your name on every field(unless other developers step up and put their name for their bugs), and accept blame for every bug whether it's yours or not. Nothing will render that field or the idea of blaming someone more useless than this. If your boss asks why is your name on every field, then you can explain "because I don't think development is a blame game, if you really need people to blame and crucify, then crucify me for everything and let my team work peacefully."
I would upvote for the first paragraph, but the second one seems questionable to me. In my experience the kind of people who suggest ideas like a blame field in the first place aren't the kind of people who worry about making people uncomfortable.
@GordonM It really depends on the boss's personality. A no-nonsense, suffer-no-fools kinda guy may not look kindly on the Spartacus approach but might still be willing to admit that the field creates more problems than benefit. If the OP & team show that they respect the boss enough to try his idea, he might respect them enough to listen when they later tell him that it doesn't seem helpful. Furthermore, he may know something the OP doesn't, such as that he's about two inherit a couple of losers from another team and wants to be in a position to collect some metrics.
Additionally, the team still WILL suffer. All just to prove that boss was wrong?
I'd always put the manager's name there. "In any organisation work sinks to the bottom, while responsibility floats to the top."
@David: Both cream and scum float to the top. What are you dealing with in *your* organization?
I'm sorry to say, but having dealt with too many managers, paragraph 3 won't do anything but get you fired for "not being a team player". Managers are too stupid to understand that they've approached a problem from the posterior-end. So they won't understand what you're trying to do, even if you explain it calmly and rationally to them. Managers don't have to be rational. That is the problem, but also what tends to get them management positions.
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 colored sticker and was instructed that for any design worked on or even touched the sticker must be added to that design's paperwork.
The boss' stated goal for "the sticker initiative" was to establish the source of all our department's errors (mistakes in paperwork, misfilings, bad copy, essentially the print equivalent of bugs)
What we did was gave each of the other designers a quarter of our stickers so that we each had all the colors, and instead of putting just our color on each design we put all four of the designers' colors.
Don't just write your name in the [Blame] box- put everyone's name that is on the team/project, and make sure the whole team does the same.
We worked together against her orwellian bitchiness and as a result we actually ended up catching each others mistakes and talking to each other about it and ultimately had a significant reduction in errors. She was a sh*t manager though, and instead of recognizing that her initiative ended up uniting us and increasing productivity she got all butthurt and disbanded the sticker system and declared it a failure and formally reprimanded all of us.
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 look like the person who writes the most code is the worst programmer, and the person who writes the least code is the best programmer.