
My boss decided to add a “person to blame” field to every bug report - duopixel
http://programmers.stackexchange.com/questions/154733/my-boss-decided-to-add-a-person-to-blame-field-to-every-bug-report-how-can-i
======
reitzensteinm
The top answer has it exactly right. This should be Root Cause, since
ultimately even bugs caused by human errors are really caused by systemic
flaws. Some examples:

    
    
      * SQLite has 1177 times as many tests as code (not a typo)
      * Live television is broadcast with a 5-10 second delay
      * IMVU automatically reverts commits pushed to the site if regressions are detected
      * Netflix implemented a system called the Chaos Monkey, which randomly shuts 
        down processes. Ensures the system can survive any failure
      * VLC, Unity3D, Windows, 3D Studio Max and many more applications phone
        home crashes, which allows developers to quickly patch frequent issues
      * Code reviews and pair programming ensure no one person's mistake
        can break critical code sections
      * Similarly, multiple people should sign off on copy written. For newsletters
        and press releases the whole team should, since they can't be withdrawn
      * Well designed systems automatically backup, and those backups are 
        automatically tested, so nothing is deleted forever
    

Change "who" to "why" and a horrible idea turns into a brilliant one. Well
designed systems can reduce the risk of almost any mistake, at the cost of
speed and flexibility.

Ultimately it's up to the company to decide where the balance lies, and to
live with the consequences. Startups will accept a drastically different risk
profile to banks and Fortune 500 companies.

~~~
SoftwareMaven
I'm usually arguing against stereotyping management around here, but I find it
a stretch to believe a boss who thinks "Person to Blame" is going to be
willing to pay the cost for true root cause analysis.

I have a feeling it's more like: <git annotate>; "Oh, it's Bob's fault."

~~~
kls
We actually had a tradition at one of the places I worked at, where someone
along the way brought in a trophy and the title was changed to something along
the lines of best bug write. Anytime a bug broke the system the trophy was
passed to the person that broke the system. It was actually light hearted and
effective. We would make a big deal of passing the trophy, but no one wanted
that trophy. It was not punitive, but more of a joke, kind of a simple
reminder that I don't want to be the guy with the trophy on his desk.

------
droithomme
Joel Spolsky refused to add a "blame" field to FogBugz for years, he used this
as an example of how you should not give the customers every feature they
demand, and he said it was one of the top most requested features. He
explained that once you add that field it will be the end of fixing bugs and
making honest bug reports. Developers will work with QA so that bugs don't get
entered into the system. Long arguments will ensue about whose fault a bug
really is, and massive time will be wasted on this. One of the jobs of a
software designer is to construct a tool that encourages good ways of working
and not dysfunctional ones. New features need to be evaluated with this in
mind.

Eventually though after he turned over project management of the software to
the employees, they responded to the constant bug reports about the lack of
this feature and added the ability to have this field. I recall he made a note
about it on his blog, but that the project belonged to them and it wasn't his
project to micromanage, so now they have the feature whether he likes it or
not.

Caution: I probably have half the details wrong, I'll try to find some links.

Update: <http://www.joelonsoftware.com/news/20020912.html>

~~~
xtracto
Aaah... if only Open Source developers learnt from that Joel's article from 10
years ago!

Instead, filing a bug for Firefox, Gnome or the majority of popular open
source projects requires you to provide even the color of your socks.

------
cletus
One tradition I really appreciate at Google is the post-mortem. Any serious
outage or bug will be followed by a detailed post-mortem detailing a timeline
of what went wrong and why.

Sometimes this will go as far as establishing a "war room", possibly for
weeks, dragging in people from a number of different areas to address a
particular issue.

It's not about pointing the finger or otherwise apportioning blame. It's about
learning from mistakes and preventing them from happening again.

That being said, I've worked at other places where shame is attempted to be
used in such situations (which is what this is). In my experience it just
fosters a hostile environment.

~~~
wccrawford
A good programmer will feel shame from that whole process even if nobody
points the finger at them. The blame game just isn't needed.

A bad programmer shouldn't work there in the first place, and if they need to
be blamed, they're probably doing other things to destroy morale.

~~~
damoncali
I find it interesting that you'd feel shame over a bug. Why?

~~~
Devilboy
This is a very well-known phenomena. If you don't feel anything after a bug in
your code cost your company lots of money and your team members many days in
debugging and fixing it... then you're like nobody I've ever worked with.

~~~
jaylevitt
Really? My first major software release took the AOL mail system down for 34
hours. My later work kept it up for 8 years. I consider both equal fodder for
bragging, self-immolation, and war stories over drinks. I couldn't tell you
which taught me more.

~~~
vacri
That sounds like you feel something about both of those things.

------
Spooky23
I was a senior manager in an organization where one of my peers essentially
inserted a similar blame regime into our incident management process. It is a
poisonous practice, but I actually loved my job and wanted to improve the
place. So my team fought back.

The way that you defeat a system like this is to use it. Be humble, honest and
calm, and go out of your way take the hits. But refuse to be blamed for things
that aren't your responsibility. Force the problem people to do the same.

That undermines the system, as your putting the problem person in the
uncomfortable position of taking responsibility for his actions. The whole
point of "blame assignment" is to deflect blame from the golden children.

In my case, the blame regime lasted a few months. It collapses when the person
pushing the regime is on the defensive too often.

~~~
tomjen3
That doesn't work when you have somebody like me who would never accept blame
if it was to be written in a permanent file, because I know it would end up
being used to fuel some KPI.

And in development there is always somebody else to blame if you look hard
enough (because every time a choice is made, it has costs).

~~~
rcfox
Sure, you can spend your time looking for ways to blame other people. Or, you
could just go back to getting stuff done.

~~~
tomjen3
I do -- because I work in a shop that values getting stuff done.

But if you work in a shop that values covering you ass, then you should cover
you ass and not care too much about getting stuff done (and then make a plan
to get out of there).

------
noonespecial
The more blame you try to place the fewer commits you're going to get (and the
ones you do get will be larger and full of "defensive code"). Less commits,
less often will make the problem worse, not better because the merges will be
larger and more painful, and more subtle systemic errors will become the norm.

This is one of those solutions that causes more of the problem its trying to
solve. Management will love it.

~~~
dhimes
I came here to write a comment- and happened to click the OP link and saw that
Doc Brown and I think alike.

------
DanielBMarkham
Reminds me of a consulting story.

I was sitting down with a team getting started on Agile/Lean, and I was trying
to lighten things up.

"Well, the first thing to do is pick somebody to blame when it all goes
south," I paused for effect, "and that's usually me, the consultant."

It was dead silent. Everyone in the room was looking at me seriously.

Tough crowd.

~~~
roguecoder
I had a new PM come in and give a similar speech. "If we fail spectacularly,
it is going to be my job. But if we just fail, it is also going to be my job.
More importantly, in neither case is it going to be your job. So now is the
time when you can do spectacular things in utter safety; I'm asking you to
take this opportunity and run with it!"

------
starpilot
Warren Buffett practices, "praise by name, criticize by category." This is the
opposite.

~~~
smacktoward
The way I've heard that principle phrased is "praise in public, criticize in
private."

It's good advice, because criticizing people in public (i.e. in front of their
peers) always backfires -- it just makes the criticized person defensive, so
they stop being open to learning from their mistake.

------
ajuc
We have such field in JIRA too. At first it wasn't required, so nobody filled
it. So it was made required by upper management.

People filled it mostly with our boss (we agreed with him, that when it's hard
to say whose bug it's - we assign it to him), or old workers, that work here
no longer, that first made commits to the feature where bug is. Or people
solving the bug assigned it to themselves. Only sometimes somebody assigned a
bug to another programmer who still works here.

Now the field is optional again.

------
suresk
I wish bug trackers were better equipped to help find the real root cause of
bugs, and more teams actually tried to track that data. Were the specs bad? Is
there a problem with our process? Did we not write enough tests? Did someone
just screw up?

As it is, bug trackers are good at collecting information and letting you
create a process that is as convoluted as you'd like to track the work towards
coming up with and releasing a fix, but leave much desired when it comes to
trying to reduce your overall defect rate.

That said, trying to pin the blame on someone is the absolute worst way to
accomplish any of this, and virtually guarantees that any "root cause"
information you try to gather is going to be completely useless.

~~~
jacques_chester
> I wish bug trackers were better equipped to help find the real root cause of
> bugs, and more teams actually tried to track that data. Were the specs bad?
> Is there a problem with our process? Did we not write enough tests? Did
> someone just screw up?

Some of that comes back to the concept of requirements traceability.
Unfortunately it didn't quite make the agile cut. So it's languished in the
pre-agile SEng world, locked up in clunky, heinously expensive tools.

------
bambax
I had this to say but can't post it on the site:

The European Directive 94/56/EC [1] "on the investigation and prevention of
accidents and incidents in civil aviation and repealing" states that:

> ‘causes’ means actions, omissions, events, conditions, or a combination
> thereof, which led to the accident or incident; the identification of causes
> does not imply the assignment of fault or the determination of
> administrative, civil or criminal liability;_

(Art. 2 part 4).

This is said again in the preamble of the same directive, paragraph 4:

> The sole objective of safety investigations should be the prevention of
> future accidents and incidents without apportioning blame or liability.

I'm sure there are many other legal texts (including in the US) that state the
same thing, as it's plain common sense: assigning blame and getting to the
root cause of a problem are two very different and separate businesses; both
are necessary but shouldn't be conducted by the same personnel and not at the
same time.

[1]: [http://eur-
lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2...](http://eur-
lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2010:295:0035:0050:EN:PDF)

(Why HN doesn't support Markdown, we'll never know.)

------
zdw
Time to file a bunch of "Corporate culture in rapid decline/freefall" bugs...

------
chrislomax
Although I tend to agree that morale would decline I do not know the full
story of the working environment.

If you have an idiot coder that has been there forever and is hard to get rid
of then this field would come up in their evaluation. Needless to say it may
get overlooked on other peoples evaluation. It may be used as a way to manage
some muppet out the company for wasting everyone's time.

But I don't know the full story, the boss may be a control freak and an idiot
himself but he may be actually trying to improve working conditions, he just
chose the wrong terminology for the field.

------
notJim
At the right company, this field would be hilarious and fun.

------
jacques_chester
Contrast with the Personal Software Process, where each programmer keeps
_personal records of every mistake they make, no matter how minor_.

That the records are personal -- they belong to the programmer -- is repeated
again and again.

Because when you keep management-accessible records like this, three stages
occur:

1\. "We won't use this to judge your performance and it will not be connected
to reward or punishment".

2\. It is eventually connected, directly or indirectly, to reward or
punishment.

3\. The indicator is gamed.

------
ragincajun
I've always said that failure is the best learning experience. It's okay to
make a mistake. Just don't make the same mistake twice.

PS. Your boss is stupid.

~~~
alan_cx
I so agree. Do something right and you have just done something right. Make a
mistake and learn from it, your knowledge has grown.

------
kepioo
huuu - some links you may want to send him read:
[http://codeascraft.etsy.com/2012/05/22/blameless-
postmortems...](http://codeascraft.etsy.com/2012/05/22/blameless-postmortems/)

and if he'd rather check it out in his car, have him listen to John Allspaw
and Mike Rembetsy talking about blameless postmortem on the food fight podcast
(the relevant part starts around the middle of the show):
[http://www.foodfightshow.org/2012/05/episode-14-live-post-
mo...](http://www.foodfightshow.org/2012/05/episode-14-live-post-mortem-with-
david.html)

------
viscanti
A company can likely be 10x (or more) productive if they're shooting for 99%
of code being "good enough". It's understood that sometimes mistakes will
happen, but you get a lot more done when you know 99% bug-free is OK. What
happens with the blame game is that many employees now start to focus on
hitting that 100% level, which significantly slows things down, and probably
still doesn't result in hitting that 100% bug-free mark. It's just a really
bad idea, and is probably instituted by non-technical management.

------
hackoder
A lot of ideas sound great to management, and they work too! I mean, other
than killing employee morale and resulting in long term loss ;-)

At one of my past jobs, we worked like consultants (we quoted hours that a
task would take to get done, tested etc). We filled daily timesheets to ensure
that our hours did not exceed our estimates. In fact, the time on those
timesheets had to total 40 hours every week. So we worked the full 40 hours.
And we billed those 40 hours to the client. In those few months, I was as
productive as I've ever been.

Unfortunately, we weren't paid like consultants.. we got a regular salary.
Management was doing nothing wrong. They failed to realize that the
'consultant lifestyle' of billing and working in hours only works if there is
an equally motivating paycheck to go with it. I've known multiple people to
leave because of how hard it was.

You shouldn't need a person to blame field. Good responsible employees will
know what they did wrong and work to fix it. And if they don't, having the
field in there will only increase finger pointing and people trying to protect
their own jobs. And your bottom line will still not improve. So why do it?

------
tallpapab
"Fix the problem, not the blame." - I first heard this in the movie Red
October, I think. The other one that come to mind is John Wooden, the famous
basketball coach, claiming that he liked players who made mistakes because
those were the ones trying to make things happen.

------
ma2rten
What is the point of posting this on stackexchange? I found the comments quite
childish:

> Put your bosses name in that field for every bug. Convince your teammates to
> follow that practice, then wait how long this nonsense will last.

> Quit. No, don't look back. Just... quit. In your resignation letter, put
> Person to Blame: [Boss's Name]

What I would do is try to explain to them calmly and patiently why this is a
bad idea. If this does not work, then just refuse putting blame on other
people, and encourage others to do the same. If you really must do something
childish to protest, put your own name on every bug that you file together
with a nonsensical reason why are to blame for it.

~~~
pbiggar
But of course. Comments on StackExchange are for quips that aren't whole
answers, and they're limited to 600 chars so that can't be much more than
quips. The real high quality responses are in the answers.

------
snorkel
Bad, bad, bad idea. The result is the devs who do most of the coding will get
most of the blame that only demoralizes key contributors.

Unless you're also awarding gold stars for every bug-free line of code then
this is just an unproductive disincentive.

------
motters
What happens when there is a "culture of blame" is that innovation falls to
zero (or lower). When people are scared of being blamed for things, and
potentially also fired with little prospect of re-employment, then they just
stick very rigidly to whatever they believe their job description to be, and
never seek to explore new possibilities. The classic phrase is "it's more than
my job's worth".

In a culture of blame anything new or different is seen as bad, and to be
avoided at all costs, because the unknown nature of the new might also bring
blame with it.

------
Too
Reminds me of a case a friend had at his work. They had a (chinese)
subcontractor that failed to deliver the component on time so they asked for a
report on why this happened and the how it could be prevented in the future.

They expected a long report with the root causes behind the delay, like
unclear specifications, wrong estimation scope, unforeseen technical issues
etc. Instead they got back a very short and concise reply: _"We will find the
guilty, and we will punish them"_

------
swa14
the git dcvs has a git-blame feature. I guess it depends on the right
environment for such a feature to be productive, which would basically mean an
environment where "Blame Jim" means, "Go directly to Jim, he's either the goto
person for this issue, or likely knows where to get it fixed quickly", instead
of "everyone point the finger at Jim". Judging by the massive amount of
negative reactions here, I guess there aren't a lot of productive environments
available.

------
tomkin
Sounds like you have a large team if it's gotten so out of hand that you need
to add a field. So isn't your boss the one at fault for hiring a bunch of shit
programmers?

Hiring a bunch of shit programmers and putting up a blame field is like trying
to patch the Titanic with a band-aid. If your programmers are shit, your boss
is the one to blame and should be fired. Adding a blame field will just incite
demoralizing outcomes for those who make _regular human mistakes_.

------
strictfp
As one commenter already said: the best way of avoiding blaim is to not make
any major modifications or write difficult code. This way you avoid creating
bugs. So there is a huge risk that this will reduce productivity.

A root cause analysis should ask "five whys" as to why this happened. Tight
schedules, bad specs, improper training? Blaiming everything on the individual
who checked the code in is not going to be very accurate, and probably very
bad for morale.

------
chuckp
Or they could replace the "person to blame" field with a commit revision. It
is less personally offensive as the "person to blame" field and still gets to
the same analytic data for reviews.

I do agree a "person to blame" field was obviously implemented by a
"management only" oriented person to probably cover his/her own ass.
Essentially this is a scorecard to give to his higher-ups to say "Hey look Bob
is the one with all the issues, no me".

------
vinhboy
Am I the only person who thought this might just be a joke, or a way to make
the whole bug fixing process more light hearted... I don't think I would be
offended if my name got put on such a field, because I am sure everyone would
end up on it eventually. Reminds me of the time we passed around a duck toy in
the office to anyone who screwed up that day.

------
richardlblair
Time to find a new job. When the people you work for turn into dicks and it
makes your work less enjoyable it is time to move on.

------
jarofgreen
Ummm ... so I saw this Q on Stack Exchange before it hit hackers news. There
used to be a lot more comments (yes, many of them jokey but still useful, I'd
argue). Apparently, at some point after it hit Hackers News it was cleaned up.
What do people think about the moderation on Stack Exchange sites these days?

------
Hominem
When talking about screwups I aways say "we" assuming the developer will
internally acknowledge that "we" probably meant them. Then again, I always
feel somehow responsible for an issue even if it is a totally different team.

------
bconway
Things like this rarely happen in a vacuum. There is no doubt a much larger
issue of responsibility (or lack thereof) going on that led to this drastic
action.

But yes, as mentioned, "Root cause" is a better approach.

------
petdance
That kind of mentality is exactly why it's wrong to have "svn blame" and "git
blame" as commands. The very commands that we use to look at code history
teach us that it's all about finger-pointing.

~~~
eru
I always understood `blame' to be a light-hearted nickname, and `annotate' to
be the official names of these commands. By the way, mercurial also has a
`praise' synonym, if memory serves me right. (Or was it another one?)

------
damoncali
Perhaps a beter approach would be "root cause of failure". It's easy to jump
all over this guy, but what he's trying to achieve is a good thing. I just
don't agree with the tactics.

------
AznHisoka
Blame the product manager or customers for coming up with the new feature
requests. If they didn't give you anything to code, there wouldn't be any
bugs.

------
tgrass
Response from the boss: <http://news.ycombinator.com/item?id=4179298>

------
dennisgorelik
If person is never mentioned in "person to blame" field, then boss should
question whether that person has any meaningful contribution.

------
firichapo
Just put 'God' in the field every time. On a more serious note, this will most
certainly decrease the quality of the work environment.

------
ww520
People make mistake, 100% of them. People who don't haven't tried hard enough
or haven't gone out of their comfort zone often.

------
gte910h
Root Cause is great, exactly as the poster says.

You actually have to a analysis to determine this though, and not just load it
off on someone.

------
sidcool1234
This is hilarious and scary at the same time.

------
jroseattle
Pointless field of data -- the only reason any information should be collected
should be to help resolve the bug.

------
greyfade
A blame field is unnecessary.

Just note the broken revision and `git blame` or `svn annotate` or whatever
equivalent you have. :)

------
sageikosa
That should be normalized to a separate table with a one to many relationship,
including a weighting factor.

------
hhaidar
At my company, we have a written rule to blame our VP for any and all
problems.

It let's us focus on fixing stuff.

------
chris_wot
The simple solution is to add the boss's name to every bug report.

------
jason_slack
This reminds me that I have not watched "Office Space" recently.

------
mattvot
Facebook implements a system similar to this. Devs who screw up are negatively
scored (I think its a star based system). Low stars mean you are less trusted
etc.

~~~
ajtulloch
This is false. You're talking about the push system, which is an entirely
different kettle of fish.

------
EdiX
It should be called the "flame bait" field.

------
freefrancisco
Is "your mom" an acceptable answer?

------
jccodez
Tell him to watch "office space".

------
christopherslee
you should blame the product owner/manager/guy for writing incomplete/vague
specs.

------
Tichy
Just don't use it.

------
ktizo
Anything like this automatically makes me reach for a suitable Dilbert
reference... oh, here's one - <http://dilbert.com/strips/comic/2008-06-02/>

------
yashchandra
Person to blame: A

Boss to 'A': what happened ? why the bug ?

'A' to boss: I just checked in the code. It was done by 'B'.

Boss to 'B': hey what happened ? Why the bug ?

'B' to boss: I just merged the code from 'C'.

boss to 'C': hey what happened ? Why the bug ?

'C' to boss: My code worked fine when I unit tested. I gave it over to 'D' to
integrate.

boss to 'D': hey what happened ? 'D' to boss: I integrated fine when I did. It
is the damn software that might have crashed at the time and code was not
integrated properly.

boss to himeself: Fuck it was the damn software.

~~~
rcfox
Boss to the team: That's it, no more software!

