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?

  • 95
    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
    Commented Jun 29, 2012 at 22:01
  • 121
    "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
    Commented Jun 29, 2012 at 22:23
  • 41
    @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
    Commented Jul 1, 2012 at 7:25
  • 80
    @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. Commented Jul 1, 2012 at 16:24
  • 102
    Your boss is the "person to blame", fill his name in always and see how he likes it ;) Commented Sep 15, 2013 at 16:15

29 Answers 29


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 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.

  • 14
    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
    Commented Jun 28, 2012 at 20:28
  • 3
    @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
    – gnat
    Commented Jun 28, 2012 at 20:33
  • 17
    "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". Commented Jun 29, 2012 at 5:02
  • 33
    Great. Even your example for a single responsible person features two people, perfectly illustrating the stupidity of the exercise.
    – Urs Reupke
    Commented Jun 29, 2012 at 5:46
  • 16
    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.
    – Jan Hudec
    Commented Jun 29, 2012 at 13:53

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.

  • 327
    Well, the boss will be happy! There'll be fewer bug reports, and therefore, the quality must have gone up. Commented Jun 28, 2012 at 21:27
  • 6
    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.
    – Matt Wilko
    Commented Jun 29, 2012 at 12:35
  • 68
    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. Commented Jun 29, 2012 at 13:50
  • The Person Reporting the Bug will not likely be the person that is the root cause I mean think about trying to find a an error in your own code after 36 hours of writing code this week?
    – Malachi
    Commented Sep 28, 2012 at 18:46
  • 3
    Malachi. I worked with a guy once, and everything he touched broke. Whether it was code that he hadn’t written or office furniture, he touched it, it broke. I would not have hesitated to add him as “root cause” of any bug he reported:-)
    – gnasher729
    Commented Oct 25, 2020 at 17:57

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 accountability yourself, but in a way that actually makes sense to you.

  • 5
    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.
    – Doc Brown
    Commented Jun 28, 2012 at 20:18
  • @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
    Commented Jun 28, 2012 at 20:22
  • @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.
    – Doc Brown
    Commented Jun 28, 2012 at 20:26
  • 3
    This book will help you find the words to stand your ground amazon.com/The-Power-Positive-No-Relationship/dp/0553384260/…
    – zundarz
    Commented Jun 28, 2012 at 21:05
  • 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
    Commented Jun 28, 2012 at 23:14

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.

  • 20
    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.
    – user
    Commented Jun 29, 2012 at 7:42
  • 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.
    – Jordan
    Commented Jul 2, 2012 at 5:32
  • I'm fine with blaming/praising individuals. But it should be done very carefully, because it's easy to cause worse problems trying to do so than the original issue was. The 'culprit' field doesn't look like a 'very careful' approach.
    – ptyx
    Commented Jul 6, 2012 at 19:24

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.

  • 7
    Even better: Coding guidelines/standards and code review checklists updated to avoid this happening again. Commented Jun 29, 2012 at 16:09
  • 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.
    – Adam Bruss
    Commented Oct 8, 2012 at 17:57
  • 3
    @Adam: doesn't my answer directly address your exact question "What's wrong with blaming someone...?" Commented Oct 8, 2012 at 21:27

Change "Person to blame" to "Person to praise"

The main person to fix the bugs gets their name on it.

  • 11
    I don't think this answers the question. It's a good sentiment, but doesn't provide arguments against such a field. Commented Sep 17, 2012 at 18:34
  • 28
    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...
    – MGOwen
    Commented Mar 18, 2013 at 4:25
  • Very often, you want to know who wrote the code and who's best qualified to fix it if it goes wrong. Part of the backlash of "person to blame" is that it implies that someone is blamed.
    – Muz
    Commented Apr 3, 2014 at 9:03

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 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?

  • 1
    Importantly, it keeps people from trying to do the hard jobs. Compare two surgeons, one doing heart surgery, one fixing ingrown toe nails. Who has more dead patients, and who would be the better surgeon?
    – gnasher729
    Commented Oct 25, 2020 at 18:01

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."

  • 16
    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
    Commented Jun 28, 2012 at 20:14
  • @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.
    – Caleb
    Commented Jun 28, 2012 at 20:39
  • 3
    Additionally, the team still WILL suffer. All just to prove that boss was wrong? Commented Jun 29, 2012 at 11:53
  • 32
    I'd always put the manager's name there. "In any organisation work sinks to the bottom, while responsibility floats to the top." Commented Jun 29, 2012 at 15:06
  • 3
    @David: Both cream and scum float to the top. What are you dealing with in your organization? Commented Jun 30, 2012 at 0:27

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.

  • 2
    Yours was a funny story and almost answers the question. You might consider adjusting the tone and verbiage for a more positive read. Otherwise, you'll keep getting downvoted. (I upvoted your response.)
    – Evik James
    Commented Jun 29, 2012 at 17:30

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.


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 not the sign of a good skiier; but often the sign of one that doesn't try anything (or doesn't really ski at all).

Bugs can be introduced in code by poor programming and poor design; but, they can also come as the consequence of writing lots of difficult code. Dinging people who produce the most bugs is as likely to Ding poor developers as highly productive ones.

It sounds like your boss may be frustrated with the number of defects. Are the people in your group passionate about quality? Creating a 'what' field for the cause rather than a 'who' field could be more productive. Ex: Requirements Change, Design Flaw, Implementation Flaw, etc. Even this will fail unless there is a group by-in to improving the quality of the product.


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 is the basic problem that people who think about solutions primarily in terms of individual blame are usually pretty set in that mindset.

You asked for writing on this topic, and Peopleware comes to mind. It's highly regarded and talks in general terms about how to manage people doing creative work where the output is difficult to measure. The problem is that you reading it won't help much, your boss would have to read it, and believe at least some of it.

Oddly, since the problem here is more about people than bug reports, it very possibly belongs more on Workplace than Programmers. But the success of software projects is usually pretty heavily traceable to human social interaction, so the real answers are often mostly about things that transcend software.

My only other, half serious, suggestion is to say (or convince a co-worker to say, since you plan to leave) that you are willing to take on full responsibility for the project's success, and your name should always go in the field, since even if someone else made the mistake directly, you have assumed responsibility for making sure everyone on the team does quality work.

It's nonsense of course, how could you ever back that up, but some people (especially people who are big on blame) really eat that stuff up. Ronald Reagan used to publicly accept personal responsibility every time any member of his administration was caught in a scandal (and there were quite a few) and it actually worked out pretty well politically every time. The best part for you is that the responsibility generally comes with no actual consequences, they just think you are a stand up guy for taking the responsibility.

Or maybe that's not how it will go down. It makes no sense at all to me so it's hard for me to predict when it will work, but I have witnessed it work when it seemed to have no business doing so (in the workplace, not just the Reagan example).

  • +1 for suggesting explaining positively how to manage information workers, rather than just attacking this one idea. Commented Jun 29, 2012 at 16:10

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 score, instead of solving problems related to the software they are working on.

For example, trying to submit a bug report with a wording to lessen one's own blame, and shove it on someone else can lead to developers misunderstanding the cause of the problem (or the work being given to another developer who does not know that section of a code as good as the one who was working on it the most and who was the primary cause of the bug) leading to more time and effort to fix the problem.


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 code is any better. Code will never get checked in.

At some point a manager should know who is doing their job and who isn't, as well as, who does it better because the rest of the team does.


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 events from occurring, would be good. Sometimes the solution is nothing more than additional training. I've worked for a number of companies where it was part of your job description, to get a "company paid/company time" education. One place even built an entire "training center", that the local college "borrows" on occasion, for their industrial technologies courses.

I have worked in a manufacturing environment for the last 20 years, where programming mistakes don't just cause errors, they physically destroy things, and/or worse, they get people hurt. However, one constant in every field of manufacturing that stands strong, is that there is never, under any circumstances, someone to blame. Because it's a defect in the system, plain and simple - not a defect in the people. Look at it this way - the use of spell checker - a highly effective tool, for those less fortunate in the area of textual virtuosity, or maybe just those a little over worked... but by no means a method of blame or accountability.

A work environment, no matter what kind, or for what purpose it serves, is a system. A system made up of individual components, that if properly "in tune", works in total harmony - or some semblance of such.

Suggested reading on your boss' part: The 7 Habits of Highly Effective People

It sounds like he could use a little humility, if not a reality check. He's just as much a part of the team, as everyone else, and he needs to realize that - or it just won't work, and in the end, he will be holding the bag regardless.

Suggested reading and/or research on your part:

Look into 5 why analysis, root cause analysis... anything thing that puts you in a better position to offer a solution, not a problem. And your disagreement with your boss, is just that, a problem, not a solution. Offer him something better, something that makes sense, and even be prepared to allow him to take credit for the idea.

Right now it doesn't seem like he is prepared to fix anything, because he does not have a firm understanding of what is broken, if there is anything broken at all - other than his "I'm the boss" mentality.

Good Luck! I hope you manage to get through this, in a manner that's acceptable for all, especially in these times.

EDIT: Personally, from my own experience... "Go ahead, blame me. Because sure enough, I'll fix it, and down the road, when it happens again, who will be there to save the day? yep, you guessed it... me, with a big ole grin."

  • "puts you in a better position to offer a solution, not a problem." - yep, which is the main point of this post. I didn't expect it to blow up quite like that.
    – MK_Dev
    Commented Jul 3, 2012 at 4:35
  • In the end, it will either be a team success, or a team failure - and no matter what the course of action may be (including the blame game) will not work, or even be proven a bad idea, if not followed through to fruition or failure. In other words, the alternative to mutiny, may in fact be to just follow your bosses plan to the letter, with active participation by all - towards the inevitable collection of hard data, to weigh in favor of, or against, continuing down that path of reason.
    – tahwos
    Commented Aug 13, 2012 at 1:17

For accountability I wouldn't want a person to blame field, I would want a Person who knows the code field or a person who can fix field, so that I would know where to send the support ticket.

This would speed up the process fixing the bug itself and give accountability, kind of like killing two birds with one stone. I would personally bring this up to him and let him decide if this would help to increase morale and accountability without making anyone feel like they failed. Extreme testing doesn't catch all bugs, otherwise there wouldn't be bug reporting.


Tell him "blame" is negative. Change it to "person to fix" then at least it is framed in a positive manner, and the same job still gets done. How can people work if they are being "blamed"?!

  • 2
    You can't "fix a person"...
    – SandRock
    Commented Jul 2, 2012 at 8:28
  • 1
    We have the "person to fix" field. It's not enough
    – MK_Dev
    Commented Jul 3, 2012 at 4:38

If my boss did that the following would happen, in this exact order:

1) I would immediately start looking for a new job.

2) Every time a bug is reported with a person to blame, my boss's name would appear there, and a comment as to why a bad process in the team is responsible for it. And CC that to his boss (preferably in a batch). Do you have unit tests? If not then it means that the dev process is broken, thus the bug. Do you have constant automated integration testing with all external systems? Then the dev process is broken, thus the bug. Do you have the ability to make every environment identical in production via script to not allow human error? Then the dev process is broken, thus the bug. Is one developer terrible? Then the hiring criteria is badm thus the boss's fault. Are all developers making stupid mistakes due to lack of rest because they are working 12 hrs a day? Then the dev process is broken. As you can see 100% of the bugs are the fault of the boss.

As a side note: Every good development manager is aware of what I wrote above. And Agile strategies are meant to point out to the boss or his/her supperiors why dev is slowing down: Look, we're spending 50% of our time fixing bugs. Lets look at strategies to reduce them so we can spend 40% of the time fixing bugs, and then revisit this problem getting it to 30%. etc.

Unfortunately it sounds like you don't have a good manager because of the field. So I suggest doing (1) and not bringing it up to the manager (except on your exit interview)


It looks like your boss has not a deep understanding of software and maybe he does not intend to, either. So he has a different language, a different culture.

Quitting a job for a problem like this, before even trying to step forward for a solution is just being a quitter. Quitting is quitting. Do not quit until he makes you sure that you can never understand each other. To be sure about that, you should first try.

Since he does not know our language, and he is the boss, the first step here would be trying to talk to him in his language. What do I mean with language? Let's think together:

We software people, most of us love the job we do, we have a deep connection with what we are doing. Otherwise it does not work and one cannot go on in this business for a long time without loving it or being a complete ...you fill the blanks...

He, however, sees things much differently. With every bug report, while most of us get excited to make the thing work better (no, even if it is sometimes really very stressful, we love problems, just admit it!), he sees it as a failure, a measure of being unsuccessful. First thing he should want to understand is that bugs are good. Bugs makes clients love the company. (Now this is his language) When a customer reports a bug, or when we find one ourselves, after it is solved, it is much better than the situation it never happened. Bugs create customer loyalty (I am serious!), bugs create a great excuse to communication between the consumer and the producer of the software.

To "increase the profit of bugs" you should offer making bug reports even more open. With every bug report and its quick, clean, good solution, customers feel and see that "wow, these guys are awesome! They work really hard. Look at these things they are solving. We were not even aware that software was such a complex thing!" blah blah and blah...

Make your move, talk in his language. Bugs are great for a software company, not a problem. They make us a living.

For team ethics, efficiency, or any kind of talk you would make might work the opposite way you intended. If you want to quit, he will think "aha, my solution started to work from the very first day! Bad links have already started to drop by themselves before they are exposed!" He believes in his idea of finding the bad boys in the company and it is very difficult to convince him otherwise. Especially when you might be one of those bad boys!

So, focus on his real problem: Bugs. Show him that bugs can be very useful. Without any problems, a relationship is boring. Everything that does not kill you makes you stronger. Every bug is a great opportunity that you can use to increase the customer happiness.

This is just one thing you can tell. Think about his concerns and you will find many other items to add to your list. The GOLDEN KEY is to offer an alternative thing instead of fighting with his idea!

  • 5
    Not the downvoter, but the question explicitly said there were multiple attempts made to convince the boss it was a bad idea, so the second paragraph of your answer wasn't appropriate. Commented Jun 29, 2012 at 13:28
  • 8
    I very much disagree with the notion that there's anything wrong with quitting a job when the company is doing things is a dumb way. It is not your problem to fix the company. If my quitting confirms the boss's own logic in his eyes, that's his problem; it stopped being mine the moment I walked out the door.
    – Nate C-K
    Commented Jul 1, 2012 at 19:07
  • I prefer trying to solve anything I can. In such a situation, if I quit, company will be left without a solution, at least by me. If I can easily fix something instead of starting to something else from scratch, I prefer trying to fix. For me, in this specific situation, it is all about the calculation of the difference of effort, time, and stress/psychological-investment either way requires and also the outcome I can reach... Thank you very much for your comment. It is beautiful that we all have different world views:)
    – hasanyasin
    Commented Jul 1, 2012 at 21:14
  • Obviously if quitting was I wanted to do, this post wouldn't exist. With that say, @hasanyasin, thanks for the post - interesting perspective. The boss, however, is a tech/software/developer person, which only makes this issue more problematic.
    – MK_Dev
    Commented Jul 3, 2012 at 4:46
  • @hasanyasin About bug's goodness - It is excellent! I am sad I can't put two upvotes! I'll use it myself, too!
    – Gangnus
    Commented Feb 21, 2014 at 14:02

If you are doing Agile, and it sounds like you are from the features/stories comment. The person to blame would be the QA person that let the bug slip through, or the Product Owner / Customer that accepted the feature/story as complete with the bug in it.

I did typesetting back in the day, here is my take on it.

This is like blaming a typesetter for misspellings and other things that a proofreader should have found but missed. The typesetter made the misspelling, but the proofreader missed it, so it is the proofreader to blame for the mistake making to print, not the person that made the error in the first place.

In an Agile environment it is the QA persons responsibility to catch errors ( bugs ) and it is the Product Owners responsibility to not accept things that aren't correct. This is two levels of proof readers that should insulate the developers from things that get released, which is the only way anything should be classified as a bug in an Agile environment.

  • 3
    To make matters worse, devs are now QA's, too. I know...
    – MK_Dev
    Commented Jun 29, 2012 at 0:48
  • What a disturbing attitude.
    – pdr
    Commented Jun 29, 2012 at 10:55
  • 1
    Doing agile, the whole team is "the person to blame". Agile values team over individuals and it is the whole team developing the application, so every bug is the problem of the whole team. Think of the situation when a build fails on a CI server. The whole team should stop working and see if what needs to be done. At least this is what it should be! Commented Jun 29, 2012 at 14:47
  • @Sgoettschkes theoretically I agree with you 100%, the team as a whole is responsible for the product that is produced. But if you are trying to single out a specific individual, the people checking the work are the ones more responsible for letting it slip through.
    – user7519
    Commented Jun 29, 2012 at 14:51

I think your manager is trying to solve a problem with the wrong solution. I think maybe there is an issue that too many bugs are being released and your manager wants the developers to take more ownership and accountability towards the code that they write.

Using test driven development and setting up a continuous integration server (like Jenkins) will help to solve this problem, without introducing the "blame game". A continuous integration server is important to this because when someone commits code that "breaks the build" an email goes out to the team showing the person to blame. Since this code hasn't been released to a production environment, this type of blame is more proactive and encouraging (and fun!).

The result is that developers will take more ownership, feel more confident, and there will be less bugs in production code.

  • I agree with your first statement 100%. Those were pretty much my words when I spoke about the issue.
    – MK_Dev
    Commented Jul 3, 2012 at 4:48

Point out that if a single person's mistake causes a bug to end up in production, then there's something wrong with your methodology, or your over-all way of developing software. Point out that preventing bugs getting to production is the responsibility of the entire team.

Using either of these two arguments, see if you can persuade your boss that having the "whom to blame" field as a single-selection field would be misleading; and that therefore, it's necessary to make sure that the "whom to blame" field is a multiple-selection field. Once you've achieved this, then ensure that for every bug, everybody's name is in the field. Your boss will eventually see that any reporting on the field is futile.


Tell your boss that developing in a team needs social skills. He might even nod.

But the problem is, that this is something developers are extremely bad with. Adding tools that suggest blaming is more important than proper problem analysis is counter-productive.

Instead you need incentives to improve social skills, and the communication infrastructure you have should support that. For example, coin it positively: Name a person who is responsible for a ticket, who takes care of it.

Also start with code reviews so you can learn from each other. That spares the blames later on.

  • Remind him that in most cases he can be the person to blame. Time pressure, team member, managed priorities, selected/approved tools ...
    – BillThor
    Commented Jun 29, 2012 at 2:33
  • Oh man, I know developers. They often look for the cause by somebody else. And they are not shy to argument. I'd say, developers need to proactively look to improve their social skills and their accountability. The blame field can only be a symptom that in the development process something is going wrong. I bet the developers have their responsibility in that problem. The manager has too, looks like the bugs are growing over their heads. So they better should do some analysis why the bugrate has put them out of focused development.
    – hakre
    Commented Jun 29, 2012 at 8:33
  • 4
    -1 for suggesting that developer == no social skills. The two are unrelated entirely. You can be good at one, or both, and be bad at one, or both, and there's no connection.
    – Daenyth
    Commented Jun 30, 2012 at 6:48
  • @Daenyth: It was meant as provocation, so nice I see you being provocated. Sure these correlations are naturally not true, and it's dumb to say so (prejudice). However, often developers have no social skills. Especially those who work in a company that is managed the way OP outlined I'd assume.
    – hakre
    Commented Jun 30, 2012 at 10:33
  • @hakre: If it's the case where he works, then it's only because the more adroit ones have left the company due to the management
    – Daenyth
    Commented Jun 30, 2012 at 15:01

Just let it go. Your boss will discover on his own that it causes a problem, if it does.

Lets be blunt, you have an opinion and so does he. He is your manager and his opinion is the one that wins.

Yes you can go to war over this issue, but is it really worth it? I doubt it lasts more than 3 months before it falls into disuse.

But actively sabotaging this or screaming about it just uses up political capital that is better saved for asking for that extra time off, next raise, promotion, or when a really critical design decision is going to be made.

At that moment, when it really counts you do npt want the boss to remember that you were the person who actively sabotaged his idea for "person to blame".

Respect the office even if you do not respect the decision.

Save the stress and table pounding for decisions that are going to be much longer lasting.

  • 2
    That sort of people take politeness and sensibility for weakness. The next time he'll come with something much worse. And will be even less eager to listen to opinions. Even now he says that hurting people is fun. If you'll work together with such people you'll have to become a sadist, too, or a masochist.
    – Gangnus
    Commented Feb 21, 2014 at 14:15

To give the boss some credit, the concept of "blame assignment" is already baked into tools like SVN, and appropriate use of the data can be constructive to developers in "finding out who to talk to" while debugging, e.g.: http://www.codinghorror.com/blog/2007/11/who-wrote-this-crap.html

While I agree with gnat's response above that a Root Cause field is a good thing, this isn't the same information, and "denormalizing" the field to sometimes assign the previous developer name(s) for the affected source, and sometimes have a technical description (e.g. "didn't scale to 10000 users") will just muddy the waters. I'd advocate for keeping a Root Cause field clearly a technical description (e.g. even when a clear programmer error, have it capture details such as "IndexOutOfRange Exception when fooData=999") This can potentially provide some useful feedback when reviewed en masse, and allow for some corrective actions to be taken to resolve entire classes of issues with architectural or framework changes (e.g. improving custom container classes, top-level exception handing)

That said, adding a Person To Blame field clearly can send a very bad message and destructive message to a software team that management wants to single out and punish individual developers who break code most often. I suspect manager believes that this public scrutiny will cause developers to be more careful and self-regulating to avoid getting their names on this "wall of shame", and doesn't understand why developers would feel threatened by this, especially if it is added generically to every bug report.

The problems with adding this as a bug field/potential metric are easy to start enumerating:

  1. Bugs are highly variable in difficulty to resolve, and a simple statistic of bug count/developer will not reflect this.
  2. Developers are highly variable in capability " " " " " " " " " " "
  3. Many software systems have components that need refactoring, however refactoring legacy components (particularly if the legacy base has no/limited unit testing facilities) will initially introduce bugs. Developers are likely to be discouraged from this "good" activity, if there's a stigma/fear associated with generating new bugs (even if these are trivial to resolve and the end result a major improvement in the system.)
  4. Testers may file a highly variable number of bugs related to the same issue, resulting in highly skewed bug counts/developer, unless a more detailed analysis is done.

That's just the tip of the iceberg. Combine these with the finger-pointing of who expected what API behavior, incorrect expected results in tests, and "earlier in the chain" issues with incorrect/missing requirements, and it should be obvious that a metric like this is doomed as valueless (unless the goal is to damage morale and cause a mass exodus.)

Back to the boss viewpoint, it's OK that he/she wants to find out if there are developers who are breaking code repeatedly, and to try and do something (hopefully constructive) about that. Trying to get this information by adding a field to bug reports is not going to provide meaningful information for the reasons listed above. In my experience, this information can be learned by being plugged in with the team, participating in most of the team meetings, integrating (carefully) information learned in occasional one-on-one meetings with team members, and getting familiar with the subsystems in the code (even if they can't read code.)


Email him this SO question. If he's open to reason, the comments here will provide sanity checks for his reasoning. If he's not reasonable, you're unlikely to convince him with reasons that make sense. Additionally, he'll be able to read the reasons outside of a conversation (which can sometimes be more convincing because of the removed motivation to "be right" in the heat of a conversation).

You could also try to turn it around. The field could be "possible steps to avoid a similar bug from occurring", or something shorter to that effect. Then you could pool up solutions and vote on which ones to implement to make your workplace better. Perhaps a solution-oriented approach is more productive and likely better received (provided that there's actual follow through on the revisiting of suggestions).


I see two possibilities here: He wants to be able to punish people who make mistakes, or he just hasn't thought it through. Let him know that the perception to everyone will be that he intends to punish those who make mistakes. Ask him if that's the culture that he wants to encourage.

my boss decided that adding a "Person To Blame" field to our bug tracking template will increase accountability

In my experience, when management wants to "make people more accountable," what they mean is they want to be able to exact punishment for failure. Whether it's to fire poor performers, or just let them get dinged in the yearly salary review ("Sorry, Bob, you had 17 bugs flagged as your fault, and that's over the limit of 15"), it's punishment.

He'll probably say "Oh, no, we don't want that," so then ask him how that data will get used. Remind him that you don't add data points to a database unless you're going to use it. Does he want to either select on a given criteria ("Show me all the open bugs in the report creator subsystem"), so that you can work on things, or to be able to get aggregate data ("Which subsystem has had the most bugs"), so that you can do post-mortem analysis. Does he envision some sort of tote board of failure where people can be publicly humiliated?

So which does he intend? Does he want to be able to say "Show me all the bugs that are Bob's fault?" Why? Or does he want to be able to say "Show me who is at fault most of the time?" Why? The first one is not meaningful, and the second is only punitive. Or the third option is that he has no real reason.

I admit there is the possibility that he could be looking for those programmers on the team who need help in improving their skills. If so, there are better ways to capture this information that don't create a culture of finger-pointing.


I would suggest a combination of:

  1. Humour
  2. Logic - preferably razor-sharp
  3. Positive framing.

For example you could create a bug: 'Person to blame' field fails to capture root causes and fails to address systematic process issues

In the bug:

  1. Acknowledge reasons behind "the boss's" reasons;
  2. Professionally explain that the field doesn't work if the problem is in the process, external factors, etc.;
  3. (optional) explain impact on the morale;
  4. Propose:
    • introducing 'Root cause' field or other suggestions to improve capturing root causes,
    • introducing 'Champion to help avoid in the future' field. This would be the empowered senior person who can make meaningful changes to avoid this kind of issue in the future.
  5. Do not put the "the boss's" name in the Person To Blame field. Everybody knows whose idea it was.

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.

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