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?

Question

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?

Answer 1

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

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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 input and the program crashed dividing by zero.

Right:

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.

Answer 6

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

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

Answer 7

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?

Answer 8

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

Answer 9

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.

Answer 10

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.

Answer 11

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.

Answer 12

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

Answer 13

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.

Answer 14

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.

Answer 15

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

Answer 16

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.

Answer 17

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

Answer 18

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)

Answer 19

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!

Answer 20

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.

Answer 21

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.

Answer 22

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.

Answer 23

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.

Answer 24

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.

Answer 25

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

Answer 26

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

Answer 27

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.

Answer 28

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.

Answer 29

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.