
Why I added a "Peson to Blame" field to our bug tracking system - person_to_blame
So a few days ago I added a "Person to Blame" field to our bug tracking system and this decision has attracted a lot of attention from outside of our organization.  I totally welcome the debate and love the passion from everyone.  Given the interest, I thought I'd share how the "Person to Blame" field works for our team.<p>We are a tight-knit dev team, part of an almost-3-year-old startup.  As a team, we spend a lot of time together and just like other startups, we probably spend more time with each other than with our families.  We only hire people who we respect and take pride in the team that we have built.  We are a shop that believes in peer code reviews, unit testing and open debate.  We also hold each other accountable when we do silly things.  For instance, if you break a continuous integration build you drop a $1 in the jar for our beer fund.   Oh, you also get a nice dose of tongue-in-cheek lashing from the team if you write a time bomb into our unit test suite.  All in all, we have fun together, we push each other to be great and we respect each other enough to be direct and honest.<p>About 6 months ago, we made a conscious effort to reshape our software development process in preparation for Continuous Deployment.  We promote an environment where developers are in charge of a story from start to finish.  This includes understanding the problem, thinking about how a story needs to be tested, implementing the solution, writing the necessary unit tests and functional tests, and ways to measure the effect of the story once in production.  As soon as a developer okays the story, it's included in the next release.  In short, we want to be a continuous deployment shop and we think that we have the right developers to do it.  (to be clear, we are still a few months away from the true continuous deployment process like the one installed at Etsy)<p>More than just tools and process, continuous deployment requires a different kind of mentality.  While the throw-my-stuff-over-the-fence mentality never existed on our team, we do need to introduce a higher level of responsibility and accountability from everyone on the team.  Since the shift about 6 months ago, we have seen an increase in the number of hot-fixes going out between deployments.  And that's okay, bugs happen. We anticipated the increase in production bugs when we moved away from having a dedicated QA team.  But, as we get closer to having a true continuous deployment system in place, we need to start treating production bugs as the exception rather than the rule.  Bugs are inevitable and are accounted for in the world of continuous deployment, but bugs should still be avoided if possible. So a few weeks back, I started talking about keeping metrics on production bugs: count per sprint, per developer, per team, etc.  I mean, you have to start tracking these things so that you can improve, right?  And to keep the accounting simple, I added a "Person to Blame" field to Jira a few days ago.  Could I have named the field something more politically correct, so that feelings don'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.<p>Like I said in the beginning, I welcome the debate on the matter and appreciate the passion from everyone.<p>The "Person to Blame" Boss :)
======
scott_s
_Oh you also get a nice dose of tongue-lashing from the team if you write a
time bomb into our unit test suite._

 _Could I have named it something more politically correct so feeling doesn't
get hurt? Sure. But what's the fun in that? ... so why not throw in a small
dose of public shaming for good measure?_

Those statements are huge red flags to me.

As the boss, it's easy to forget that _you're the boss_. The people who work
for you will perceive and experience your actions very differently than you.
Something is "fun" to you may be hell for them because they don't have power.
Your goal is a good one, but I get the impression that you don't have an
intuition for power asymmetries.

------
jgeorge
As the boss, finding "fun" in "public shaming" is a really, really, bad idea.
It may be fun to you, but to the person being shamed, it's not any fun when
it's coming from a superior.

The day my management puts a "person to blame" field in the tracker because he
thinks public shaming is amusing is the day I update my resume and GTFOD with
great haste because that's the day my management stops caring about my ability
to be anything other than a scapegoat.

~~~
briandear
I totally agree. It's adios time. At least in NYC there are hundreds of
developer jobs unfilled with great pay and no "person to blame." Great
developers are hard to find, apparently, so are great bosses.

------
briandear
You guys use Jira? I think the person to blame is you. The friendly "public
shaming" might also be counterproductive as it will discourage developers from
doing anything to rock your very carefully managed boat. As far as production
bug preventing, that's what a dedicated QA team is for. You said it yourself,
"We anticipated the increase in production bugs when we moved away from having
a dedicated QA team."

Putting the QA job on the developers is fair enough, I guess, however it would
seem like you neglect using proper staging environments to ensure that broken
code never sees production.

At my place, we have a staging environment for every team, then we have a
company staging environment then stuff goes to production. The product manager
and team devs test at the team level staging, then it moves to the company
staging server where QA (or another developer) tests and then it goes to
production.

We do Continuous Integration as well but we sure as hell don't have a "Person
to Blame" -- we are a fucking team. The person to blame is the boss that lets
shitty code make it onto production.

So I guess it would be easy to fill out the "Person to Blame" box.. just type
your own name in every time.

------
dmlorenzetti
_So a few days ago I added a "Person to Blame" field to our bug tracking
system... I thought I'd share how the "Person to Blame" field works for our
team._

You added the "Person to Blame" field a few days ago. Therefore you're
describing how you _think_ the field will work.

To be clear, I don't have a horse in this race. I'm sole dev on the things I
make, so the bugs always point back to me. But I do notice that you're arguing
from intention, rather than from experience. Whereas the arguments others have
raised against this field are largely based on observations about what similar
decisions have done to other teams.

I also have to wonder about your idea that blaming people is going to change
anything (even if it is friendly and family-like). You described how you
changed your process for pushing your software out the door. And you state
that the new process allows more bugs to go out the door. That sounds to me
like a real, measurable, problem, that exists somewhere besides the people
performing the process. So how is calling out individuals going to fix
whatever actual, underlying problem was introduced by the new process?

------
MartinCron
You're all about transparency and openness and accountability and public
shaming, but you don't have the courage to post under your real name. Nice.

------
gazarsgo
You sound like you are siloing your developers by having individuals in charge
of stories and also being the gatekeeper to production. You should be baking
TEAM review and TEAM approval into your development process especially if you
want to start doing continuous deployment, and it sounds like you have jumped
off a cliff without a parachute if you have eliminated dedicated QA...

If your team decides they want to involve some public shame in their processes
that's one thing but it's extremely dangerous for any manager to introduce
themselves and it should never relate to production.

The team owns the code.

~~~
nickler
Innovating practices are always about iteration and learning. The tragic point
here is that the learning is being done in a public forum.

Team accountability is a best practice because trickle down hierarchies tend
to do just that...trickle down. Depending on the size of the teams, share
victory, share defeat should always be your mantra.

I don't know the size of your organization, but if you need to track these
issues with automated metrics, you may have a larger communications problem in
your workflow.

People are always better managers than spreadsheets. Use your metrics to
support your initiatives, but use your people to come up with them.

------
hobin
Ahem.

I am somewhat disappointed that you have not presented one solid argument in
favor of this new 'person to blame' field. The whole idea seems to hinge on
the following quote: _"so why not throw in a small dose of public shaming for
good measure?"_

And the answer is simple. It doesn't do any good, and can only hurt the
performance of you and your team. Let me put this as simple as possible:
shaming DECREASES performance. The fact that you apparently think this is
'fun' does not change this.

I will now return you to your regularly scheduled debate.

------
jodrellblank
What's there to debate? You think shaming people is fun and helpful, you
dismiss caring about your employees feelings as "political correctness".

If that works for your team, you're either very skilled at picking the right
people for your management style, or you're lucky, or you can't read people
and only think everyone's enjoying it as much as you are. I can't tell from
outside.

"Respecting each other enough to be blunt and honest"? What about respecting
each other enough to be kind to inherently imperfect humans? Who knows how to
read your statements without seeing your interactions first hand.

------
molecule
You 1) failed to proof read the title of this post, 2) kill morale w/ this
JIRA field, and 3) are an asshole.

<http://en.wikipedia.org/wiki/The_No_Asshole_Rule>

~~~
mrxd
Hey come on, there's no need to nitpick. We all know he meant to write "Peon"!

------
jarofgreen
So what do you think about the highest rated answer on
[http://programmers.stackexchange.com/questions/154733/my-
bos...](http://programmers.stackexchange.com/questions/154733/my-boss-decided-
to-add-a-person-to-blame-field-to-every-bug-report-how-can-i) \- namely that
there should be a "Root Cause" field instead?

------
vikram
You are the management. It's always your fault. If you didn't actually write
the bug. You could have trained the person who wrote the bug. You could have
reviewed her code. You could have not let them check it in. You could have not
let them work on the feature. You could have not hired them.

You could have fired them.

All this helps you do in a twisted way is figure out who you should fire.
Chances are people will leave long before that.

Even though I'm not the boss of my team. Our policy is that it's always my
fault. I find it liberating. Gives me an opportunity to learn from all our
mistakes. And there is no finger pointing. Unless its at the management. As
its always the managements fault.

------
shokwave
Hey. There's a problem you want to solve, and you tried a way of solving it.
Now everyone's waving their arms about and yelling at you. Right now, you're
going to feel like you should stand by your decision.

That is a mistake.

That is a mistake, even if your solution is the _best_ solution to the
problem.

It's a mistake because if you dig in, fight hard, and refuse to surrender - if
you entrench - then the solution becomes entrenched. And if all this backlash
can't uproot it, well, what possible chance could a better solution have of
replacing it?

------
bsg75
If you need metrics on who to "blame", your hiring and management practices
are faulty. These numbers will do nothing to increase "responsibility and
accountability", but are more likely to add friction, perhaps where there was
none previously.

You may end up losing the strong members of your team who have no desire to be
subject to such shenanigans.

------
spinchange
So your competent and accountable employees spend more time working for you
than with their own families and you think shaming them is a smart thing to do
for good measure?

Please do report back on what kind of novel management techniques you're using
to refill these positions in few months.

------
dantewest
As management, we should always be aware of the employee that needs that extra
coaching (don't call me soft cause I'll fire them if 2 months of coaching
doesn't work. It is a startup after all). However, this public shaming seems
like one's inability to figure out who needs more guidance and/or one's lack
of comfort-ability in having the difficult conversations that ensue once
you've identified the individual who needs extra coaching. In either case,
something tells me you're somewhat a wrong fit for this management role and I
hope your managers have the ability to identify those that need extra coaching
before you kill the spirit of your team/company.

------
fluxon
Oh, I think this hasn't gone quite far _enough_. "Person to Blame" is verbose;
I suggest "Blamee". To allow 3rd-party bug reports (gossip), please add
"Blamer(s)"; separate multiple entries by commas. Also add a checkbox for
anonymous bug reporting. Oh, and add a "Like" button and counter.

There - the descent into bugtabloid is complete.

"You're welcome." \-- John Hodgman

------
arrowgunz
Is it just me or is there anyone else too who has seen the spelling mistake in
the title? "Peson"???

------
brandoncordell
person_to_blame, you're preaching the wrong people. There are different ways
to go about this. Have you looked into Root Cause Analysis[1]? The 5 Whys[2]?

I truly can't believe someone in a leadership position is putting this type of
example out to their team. If I worked for you, I would have been out the door
as soon as you decided to keep this bullshit field.

[1] <http://en.wikipedia.org/wiki/Root_cause_analysis> [2]
<http://en.wikipedia.org/wiki/5_Whys>

------
iterationx
If you were so proud of your idea, you would have used your real account.

------
rhizome
_...if you write a time bomb into our unit test suite_

What does this mean, a slow test?

~~~
rachelbythebay
Guessing here: it might be a unit test which only works during the current
year. I came back to work from holidays in January 2011 to exactly that.
Someone had coded a test for "August 15th" being a certain day of the week. It
worked great until the year changed.

That particular test hung out unnoticed for at least 4 months. Its failure was
inevitable.

~~~
rhizome
Well that's just weird.

