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