12 ms·

My boss decided to add a “person to blame” field to every bug report

230 points by duopixel 14y ago

zdw 14y ago
Time to file a bunch of "Corporate culture in rapid decline/freefall" bugs...
noonespecial 14y ago
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 14y ago
  I came here to write a comment- and happened to click the OP link and saw that Doc Brown and I think alike.
kepioo 14y ago
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-mortem-with-david.html http://www.foodfightshow.org/2012/05/episode-14-live-post-mo...
christopherslee 14y ago
you should blame the product owner/manager/guy for writing incomplete/vague specs.
deleted 14y ago
[deleted]
- scott_s 14y ago
  That is a toxic work environment, and I'm not sure from verb-tenses if you're still there or not. If you are, find another place to work. Your quality of life will improve.
  - deleted 14y ago
    [deleted]
    - scott_s 14y ago
      Do more! Practice makes better.
      - deleted 14y ago
        [deleted]
        SoftwareMaven 14y ago
        Scott means practice at interviews. Interview regularly, even when you have a job that you love, so when it matters, you are smooth and natural instead of rough and stilted. Technical skills can only go so far. It is rare that a person who is a technical master but doesn't appear to be able to participate in a design will succeed. Fortunately, that is easily fixed by getting out there and interviewing (with a bonus of maybe finding a job you love in the interim).
        scott_s 14y ago
        Indeed I do, since it sounds like his difficulty with interviews is the social, not technical, aspect of it. And the good news is that just like the technical aspect, you get better at the social the more you do it.
        eshvk 14y ago
ragincajun 14y ago
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 14y ago
  I so agree. Do something right and you have just done something right. Make a mistake and learn from it, your knowledge has grown.
sidcool1234 14y ago
This is hilarious and scary at the same time.
jccodez 14y ago
Tell him to watch "office space".
Tichy 14y ago
Just don't use it.
damoncali 14y ago
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.
richardlblair 14y ago
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.
notJim 14y ago
At the right company, this field would be hilarious and fun.
strictfp 14y ago
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.
firichapo 14y ago
Just put 'God' in the field every time. On a more serious note, this will most certainly decrease the quality of the work environment.
AznHisoka 14y ago
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.
sageikosa 14y ago
That should be normalized to a separate table with a one to many relationship, including a weighting factor.
EdiX 14y ago
It should be called the "flame bait" field.
chrislomax 14y ago
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.
suresk 14y ago
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 14y ago
  > 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.
deleted 14y ago
[deleted]
reitzensteinm 14y ago
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 14y ago
  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."
  - gte910h 14y ago
    If you tell me to blame someone every time there is an issue, and you don't let me find out why, I'm going to blame you. Because it's your fault as the boss of the department till you let us prove specifically otherwise. That's what responsibility is.
  - reitzensteinm 14y ago
    I completely agree with that - the boss in the story sounds like a lost cause. My post was more of a speaking in general kind of thing. I was going to go off on a tangent about the importance of good management, but I haven't ever had a boss (self employed then startups), so by missing half the picture I didn't really feel qualified.
Spooky23 14y ago
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 14y ago
  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 14y ago
    Sure, you can spend your time looking for ways to blame other people. Or, you could just go back to getting stuff done.
    - tomjen3 14y ago
      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).
- m104 14y ago
  This is so much better advice than "fight the system", "convince your boss", "use these talking points", etc. If the poster really wants to keep that particular job, but wants to also improve the environment, they need to start following all of the rules they don't agree with to the letter. The worst thing that can happen is that it actually improves the team somehow. It's not always the right way to make change, but in these situations it really can be the best route. Bad rules and procedures can only be (officially) recognized as such when they're actually being used. There's no need to make a mockery of this stuff, either, because time will tell whether the new rule is really helping or hurting. Like you say, humble, honest, and calm.
chuckp 14y ago
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".
jacques_chester 14y ago
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.
tallpapab 14y ago
"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.
snorkel 14y ago
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.
viscanti 14y ago
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.
ma2rten 14y ago
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.
- benihana 14y ago
  You should read the first answer, not the comments on the question.
- pbiggar 14y ago
  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.
starpilot 14y ago
Warren Buffett practices, "praise by name, criticize by category." This is the opposite.
- smacktoward 14y ago
  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.
yashchandra 14y ago
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 14y ago
  Boss to the team: That's it, no more software!
swa14 14y ago
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.
cletus 14y ago
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.
- swah 14y ago
  Interesting. That reminded me of this book "Start-up Nation: The Story of Israel's Economic Miracle" which says their military runs the same procedure in a similar way after missions.
  - Nimi 14y ago
    As an Israeli, I can vouch for the massive ass-covering that goes on there. In fact, we just had a big public ass-covering demonstration regarding the awful flotilla blockade. Regardless of what one thinks of the political aspects and/or morality of that action, the purpose was to examine why were several soldiers injured and Israel's relationship with Turkey, previously a strategic ally, deteriorated. Both these results were seen as failures of the mission. The ass covering was plain for all to see, on the national news. I agree that the Israeli army has a very substantial contribution to the high level of entrepreneurship and technological achievement in the country, but effective organizational behavior is definitely not something you want to pick up from the IDF.
    - anamax 14y ago
      > effective organizational behavior is definitely not something you want to pick up from the IDF. (1) The IDF is "ineffective" on an absolute scale. (2) The IDF is significantly more effective than most other organizations. While better isn't perfect, you can learn from both.
jason_slack 14y ago
This reminds me that I have not watched "Office Space" recently.
tomkin 14y ago
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.
bambax 14y ago
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:2010:295:0035:0050:EN:PDF http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2... (Why HN doesn't support Markdown, we'll never know.)
gte910h 14y ago
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.
DanielBMarkham 14y ago
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 14y ago
  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!"
droithomme 14y ago
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 http://www.joelonsoftware.com/news/20020912.html
- excuse-me 14y ago
  I always just blame it on the Boogie
- xtracto 14y ago
  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.
ajuc 14y ago
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.
Hominem 14y ago
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.
petdance 14y ago
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 14y ago
  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?)
vinhboy 14y ago
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.
jroseattle 14y ago
Pointless field of data -- the only reason any information should be collected should be to help resolve the bug.
ktizo 14y ago
Anything like this automatically makes me reach for a suitable Dilbert reference... oh, here's one - http://dilbert.com/strips/comic/2008-06-02/ http://dilbert.com/strips/comic/2008-06-02/
ww520 14y ago
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.
Too 14y ago
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"
dennisgorelik 14y ago
If person is never mentioned in "person to blame" field, then boss should question whether that person has any meaningful contribution.
bconway 14y ago
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.
jarofgreen 14y ago
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?
freefrancisco 14y ago
Is "your mom" an acceptable answer?
hackoder 14y ago
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?
tgrass 14y ago
Response from the boss: http://news.ycombinator.com/item?id=4179298 http://news.ycombinator.com/item?id=4179298
greyfade 14y ago
A blame field is unnecessary. Just note the broken revision and `git blame` or `svn annotate` or whatever equivalent you have. :)
mattvot 14y ago
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 14y ago
  This is false. You're talking about the push system, which is an entirely different kettle of fish.
motters 14y ago
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.
chris_wot 14y ago
The simple solution is to add the boss's name to every bug report.
hhaidar 14y ago
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.

230 points by duopixel 14y ago

zdw 14y ago

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

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 14y ago
I came here to write a comment- and happened to click the OP link and saw that Doc Brown and I think alike.

kepioo 14y ago

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-mortem-with-david.html http://www.foodfightshow.org/2012/05/episode-14-live-post-mo...

christopherslee 14y ago

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

deleted 14y ago

[deleted]

scott_s 14y ago
That is a toxic work environment, and I'm not sure from verb-tenses if you're still there or not. If you are, find another place to work. Your quality of life will improve.
- deleted 14y ago
  [deleted]
  - scott_s 14y ago
    Do more! Practice makes better.
    - deleted 14y ago
      [deleted]
      - SoftwareMaven 14y ago
        Scott means practice at interviews. Interview regularly, even when you have a job that you love, so when it matters, you are smooth and natural instead of rough and stilted. Technical skills can only go so far. It is rare that a person who is a technical master but doesn't appear to be able to participate in a design will succeed. Fortunately, that is easily fixed by getting out there and interviewing (with a bonus of maybe finding a job you love in the interim).
        scott_s 14y ago
        Indeed I do, since it sounds like his difficulty with interviews is the social, not technical, aspect of it. And the good news is that just like the technical aspect, you get better at the social the more you do it.
      - eshvk 14y ago

ragincajun 14y ago

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 14y ago
I so agree. Do something right and you have just done something right. Make a mistake and learn from it, your knowledge has grown.

sidcool1234 14y ago

This is hilarious and scary at the same time.

jccodez 14y ago

Tell him to watch "office space".

Tichy 14y ago

Just don't use it.

damoncali 14y ago

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.

richardlblair 14y ago

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.

notJim 14y ago

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

strictfp 14y ago

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.

firichapo 14y ago

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

AznHisoka 14y ago

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.

sageikosa 14y ago

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

EdiX 14y ago

It should be called the "flame bait" field.

chrislomax 14y ago

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.

suresk 14y ago

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 14y ago
> 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.

deleted 14y ago

[deleted]

reitzensteinm 14y ago

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 14y ago
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."
- gte910h 14y ago
  If you tell me to blame someone every time there is an issue, and you don't let me find out why, I'm going to blame you. Because it's your fault as the boss of the department till you let us prove specifically otherwise. That's what responsibility is.
- reitzensteinm 14y ago
  I completely agree with that - the boss in the story sounds like a lost cause. My post was more of a speaking in general kind of thing. I was going to go off on a tangent about the importance of good management, but I haven't ever had a boss (self employed then startups), so by missing half the picture I didn't really feel qualified.

Spooky23 14y ago

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 14y ago
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 14y ago
  Sure, you can spend your time looking for ways to blame other people. Or, you could just go back to getting stuff done.
  - tomjen3 14y ago
    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).
m104 14y ago
This is so much better advice than "fight the system", "convince your boss", "use these talking points", etc. If the poster really wants to keep that particular job, but wants to also improve the environment, they need to start following all of the rules they don't agree with to the letter. The worst thing that can happen is that it actually improves the team somehow. It's not always the right way to make change, but in these situations it really can be the best route. Bad rules and procedures can only be (officially) recognized as such when they're actually being used. There's no need to make a mockery of this stuff, either, because time will tell whether the new rule is really helping or hurting. Like you say, humble, honest, and calm.

chuckp 14y ago

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

jacques_chester 14y ago

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.

tallpapab 14y ago

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

snorkel 14y ago

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.

viscanti 14y ago

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.

ma2rten 14y ago

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.

benihana 14y ago
You should read the first answer, not the comments on the question.
pbiggar 14y ago
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.

starpilot 14y ago

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

smacktoward 14y ago
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.

yashchandra 14y ago

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 14y ago
Boss to the team: That's it, no more software!

swa14 14y ago

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.

cletus 14y ago

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.

swah 14y ago
Interesting. That reminded me of this book "Start-up Nation: The Story of Israel's Economic Miracle" which says their military runs the same procedure in a similar way after missions.
- Nimi 14y ago
  As an Israeli, I can vouch for the massive ass-covering that goes on there. In fact, we just had a big public ass-covering demonstration regarding the awful flotilla blockade. Regardless of what one thinks of the political aspects and/or morality of that action, the purpose was to examine why were several soldiers injured and Israel's relationship with Turkey, previously a strategic ally, deteriorated. Both these results were seen as failures of the mission. The ass covering was plain for all to see, on the national news. I agree that the Israeli army has a very substantial contribution to the high level of entrepreneurship and technological achievement in the country, but effective organizational behavior is definitely not something you want to pick up from the IDF.
  - anamax 14y ago
    > effective organizational behavior is definitely not something you want to pick up from the IDF. (1) The IDF is "ineffective" on an absolute scale. (2) The IDF is significantly more effective than most other organizations. While better isn't perfect, you can learn from both.

jason_slack 14y ago

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

tomkin 14y ago

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.

bambax 14y ago

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:2010:295:0035:0050:EN:PDF http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2... (Why HN doesn't support Markdown, we'll never know.)

gte910h 14y ago

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.

DanielBMarkham 14y ago

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 14y ago
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!"

droithomme 14y ago

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 http://www.joelonsoftware.com/news/20020912.html

excuse-me 14y ago
I always just blame it on the Boogie
xtracto 14y ago
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.

ajuc 14y ago

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.

Hominem 14y ago

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.

petdance 14y ago

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 14y ago
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?)

vinhboy 14y ago

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.

jroseattle 14y ago

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

ktizo 14y ago

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

ww520 14y ago

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.

Too 14y ago

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"

dennisgorelik 14y ago

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

bconway 14y ago

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.

jarofgreen 14y ago

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?

freefrancisco 14y ago

Is "your mom" an acceptable answer?

hackoder 14y ago

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?

tgrass 14y ago

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

greyfade 14y ago

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

mattvot 14y ago

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 14y ago
This is false. You're talking about the push system, which is an entirely different kettle of fish.

motters 14y ago

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.

chris_wot 14y ago

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

hhaidar 14y ago

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.