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?
Best Answer
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, ....
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.