Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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? I find this sort of culture unacceptable to work in but want to try and change it before jumping ship. Any input is appreciated.

share|improve this question

We're looking for long answers that provide some explanation and context. Don't just give a one-line answer; explain why your answer is right, ideally with citations. Answers that don't include explanations may be removed.

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: news.ycombinator.com/item?id=4179298 –  Jason Jun 29 '12 at 22:01
"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. –  ulty4life Jun 29 '12 at 22:23
@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. –  gnat Jul 1 '12 at 7:25
@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. –  Danny Varod Jul 1 '12 at 16:24
Your boss is the "person to blame", fill his name in always and see how he likes it ;) –  dukeofgaming Sep 15 '13 at 16:15

31 Answers 31

I believe the key aspect to watch in here is how open the communication is in the team towards the 'boss' and the other way around. Finger-pointing is never good, however, from a management perspective, if one of your developers falls into the same issue several times, it might be time to step in and try to help him overcome this repetitive issue (e.g John is not testing properly the code: 3 production bugs in the last 3 months, let's give him a checklist so he remembers how his code is supposed to be and how he should test it).

From a development point of view, 'blaming' is already incorporated into a mainstream tool such as SVN, therefore I really don't see any harm in going "John, please fix that piece of crap you wrote" and putting a name next to it. JIRA also incorporates the name of a person when you file a bug (however the field it's not really meant for the person who's responsible for it, it's pretty much so that someone fix it).

Here's the thing though, as many mentioned above by many, if a bug arises, it's a shared responsibility: from developer, to testers, to QA, to managers. If your boss at some point handles an angry client over the phone with things like "I'm so sorry, John never tested this properly", then I'd definitely be looking for another job. A good boss should go "we'll take care of this". No names, no finger-pointing, just solutions.

Again, I believe it's all about communication. Perhaps the only thing your boss wants to do is see who's having troubles in the dev team, or what kind of problems the team is having (perhaps for training sessions?), but I don't think you will find out exactly what's behind his decision (or better said, we posters/readers) unless you talk to your boss and your entire team.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.