Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

In one of the latest "WTF" moves, my boss decided that adding a "Person To Blame" field to our bug tracking template will increase accountability (although we already have a way of tying bugs to features/stories). My arguments that this will decrease morale, increase finger-pointing and would not account for missing/misunderstood features reported as bug have gone unheard.

What are some other strong arguments against this practice that I can use? Is there any writing on this topic that I can share with the team and the boss? I find this sort of culture unacceptable to work in but want to try and change it before jumping ship. Any input is appreciated.

share|improve this question

We're looking for long answers that provide some explanation and context. Don't just give a one-line answer; explain why your answer is right, ideally with citations. Answers that don't include explanations may be removed.

40  
Hey guys, I'm the "boss" who introduced the WTF field. Here's why I added a "Peson to Blame" field to our bug tracking system: news.ycombinator.com/item?id=4179298 –  Jason Jun 29 '12 at 22:01
51  
"Could I have named it something more politically correct so feeling doesn'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." --- I think all of these "reasons" are inherently wrong. –  ulty4life Jun 29 '12 at 22:23
17  
@Jason instead of inventing Jira fields, consider hiring back one or two testers. BTW in your case having root cause field (no matter how you name it) looks low importance to me because you already groked connection between absence of testers and increase in production bugs. –  gnat Jul 1 '12 at 7:25
30  
@Jason The bug is in the code, not in a developer. You must be one of those people that thinks that code reviews are for reviewing developers, not code. –  Danny Varod Jul 1 '12 at 16:24
21  
Your boss is the "person to blame", fill his name in always and see how he likes it ;) –  dukeofgaming Sep 15 '13 at 16:15

32 Answers 32

up vote 524 down vote accepted

Tell them this is only an amateurish name for the Root Cause field used by professionals (when issue tracker does not have dedicated field, one can use comments for that).

Search the web for something like software bug root cause analysis, there are plenty of resources to justify this reasoning 1, 2, 3, 4, ....


...a root cause for a defect is not always a single developer (which is the main point of this field)...

That's exactly why "root cause" is professional while "person to blame" is amateurish. Personal accountability is great, but there are cases when it simply lays "outside" of the dev team.

Tell your boss when there is a single developer to blame, root cause field will definitely cover that ("coding mistake made by Bob in commit 1234, missed by Jim in review 567"). The point of using the term root cause is to cover cases like that, along with cases that go out of the scope of the dev team.

For example, if the bug has been caused by faulty hardware (with the person to blame being someone outside of the team who purchased and tested it), the root cause field allows for covering that, while "single developer to blame" would simply break the issue tracking flow.

The same applies to other bugs caused by someone outside of the dev team - tester errors, requirements change, and management decisions. Say, if management decides to skip investing in disaster recovery hardware, "blaming a single developer" for an electricity outage in the datacenter would just not make sense.

share|improve this answer
6  
This is a good point. However, a root cause for a defect is not always a single developer (which is the main point of this field). As a result, identifying a single developer responsible for a defect does more harm than good, IMO. –  MK_Dev Jun 28 '12 at 20:28
247  
+1 for redirecting the boss's idea into something more productive (always easier to win a battle that way) –  benzado Jun 28 '12 at 22:45
10  
"Root Cause" also covers (hopefully the majority!) of cases where no single person is to blame, things like "vendor software failure", "API documentation error", "Higher Volume Than Expected". –  James Anderson Jun 29 '12 at 5:02
19  
Great. Even your example for a single responsible person features two people, perfectly illustrating the stupidity of the exercise. –  Urs Reupke Jun 29 '12 at 5:46
12  
Don't forget that "contributing causes" would also be useful since they are often easier to do something about. For example if "root cause" was "coding mistake in commit 5678" and "contributing cause" was "commit 5678 was not reviewed because requirements came too late", than you can't avoid all coding mistakes, but you can be stricter about delaying delivery next time requirements are delayed. –  Jan Hudec Jun 29 '12 at 13:53

This sounds a lot like when Scott Adams pointed out the failed wisdom of a Bug Bounty when the Pointy Haired Boss in Dilbert. Wally announced he was going to go and 'write him a new Mini Van".

Dilbert comic strip for 11/13/1995 from the official Dilbert comic strips archive.

I recall once when Snow Skiing that someone pointed out that 'not falling" was not the sign of a good skiier; but often the sign of one that doesn't try anything (or doesn't really ski at all).

Bugs can be introduced in code by poor programming and poor design; but, they can also come as the consequence of writing lots of difficult code. Dinging people who produce the most bugs is as likely to Ding poor developers as highly productive ones.

It sounds like your boss may be frustrated with the number of defects. Are the people in your group passionate about quality? Creating a 'what' field for the cause rather than a 'who' field could be more productive. Ex: Requirements Change, Design Flaw, Implementation Flaw, etc. Even this will fail unless there is a group by-in to improving the quality of the product.

share|improve this answer

For accountability I wouldn't want a person to blame field, I would want a Person who knows the code field or a person who can fix field, so that I would know where to send the support ticket.

This would speed up the process fixing the bug itself and give accountability, kind of like killing two birds with one stone. I would personally bring this up to him and let him decide if this would help to increase morale and accountability without making anyone feel like they failed. Extreme testing doesn't catch all bugs, otherwise there wouldn't be bug reporting.

share|improve this answer

I believe the key aspect to watch in here is how open the communication is in the team towards the 'boss' and the other way around. Finger-pointing is never good, however, from a management perspective, if one of your developers falls into the same issue several times, it might be time to step in and try to help him overcome this repetitive issue (e.g John is not testing properly the code: 3 production bugs in the last 3 months, let's give him a checklist so he remembers how his code is supposed to be and how he should test it).

From a development point of view, 'blaming' is already incorporated into a mainstream tool such as SVN, therefore I really don't see any harm in going "John, please fix that piece of crap you wrote" and putting a name next to it. JIRA also incorporates the name of a person when you file a bug (however the field it's not really meant for the person who's responsible for it, it's pretty much so that someone fix it).

Here's the thing though, as many mentioned above by many, if a bug arises, it's a shared responsibility: from developer, to testers, to QA, to managers. If your boss at some point handles an angry client over the phone with things like "I'm so sorry, John never tested this properly", then I'd definitely be looking for another job. A good boss should go "we'll take care of this". No names, no finger-pointing, just solutions.

Again, I believe it's all about communication. Perhaps the only thing your boss wants to do is see who's having troubles in the dev team, or what kind of problems the team is having (perhaps for training sessions?), but I don't think you will find out exactly what's behind his decision (or better said, we posters/readers) unless you talk to your boss and your entire team.

share|improve this answer

I see two possibilities here: He wants to be able to punish people who make mistakes, or he just hasn't thought it through. Let him know that the perception to everyone will be that he intends to punish those who make mistakes. Ask him if that's the culture that he wants to encourage.

my boss decided that adding a "Person To Blame" field to our bug tracking template will increase accountability

In my experience, when management wants to "make people more accountable," what they mean is they want to be able to exact punishment for failure. Whether it's to fire poor performers, or just let them get dinged in the yearly salary review ("Sorry, Bob, you had 17 bugs flagged as your fault, and that's over the limit of 15"), it's punishment.

He'll probably say "Oh, no, we don't want that," so then ask him how that data will get used. Remind him that you don't add data points to a database unless you're going to use it. Does he want to either select on a given criteria ("Show me all the open bugs in the report creator subsystem"), so that you can work on things, or to be able to get aggregate data ("Which subsystem has had the most bugs"), so that you can do post-mortem analysis. Does he envision some sort of tote board of failure where people can be publicly humiliated?

So which does he intend? Does he want to be able to say "Show me all the bugs that are Bob's fault?" Why? Or does he want to be able to say "Show me who is at fault most of the time?" Why? The first one is not meaningful, and the second is only punitive. Or the third option is that he has no real reason.

I admit there is the possibility that he could be looking for those programmers on the team who need help in improving their skills. If so, there are better ways to capture this information that don't create a culture of finger-pointing.

share|improve this answer

Point out that if a single person's mistake causes a bug to end up in production, then there's something wrong with your methodology, or your over-all way of developing software. Point out that preventing bugs getting to production is the responsibility of the entire team.

Using either of these two arguments, see if you can persuade your boss that having the "whom to blame" field as a single-selection field would be misleading; and that therefore, it's necessary to make sure that the "whom to blame" field is a multiple-selection field. Once you've achieved this, then ensure that for every bug, everybody's name is in the field. Your boss will eventually see that any reporting on the field is futile.

share|improve this answer

Is blame necessarily a bad thing? Someone who is prepared and perhaps even happy to take the blame for something is someone who accepts responsibility for an action or inaction. This is often a sign of good leadership, not a negative.

If anything, I try to err on the side of even taking responsibility for things that may not actually be my fault because it's so hard to say. Even when another programmer made the change that introduced the bug, could it be that I failed to communicate something to them, or perhaps the test process that I put in place was too complex - or not complex enough, perhaps I didn't give them enough time...?

In my view, risk and responsibilty are key parts to being a programmer - to be productive we should be prepared to accept both.

Your circumstances will be different from my own (so this might backfire), but perhaps you should try starting a trend, so for every bug you report or review you try to find a way to add yourself as the person to blame? In this, it would be important of course to tell others that you work with of this approach - this might even result in competition for people to take the blame themselves!

Of course, if this fails - please don't blame me:-)

share|improve this answer

If my boss did that the following would happen, in this exact order:

1) I would immediately start looking for a new job.

2) Every time a bug is reported with a person to blame, my boss's name would appear there, and a comment as to why a bad process in the team is responsible for it. And CC that to his boss (preferably in a batch). Do you have unit tests? If not then it means that the dev process is broken, thus the bug. Do you have constant automated integration testing with all external systems? Then the dev process is broken, thus the bug. Do you have the ability to make every environment identical in production via script to not allow human error? Then the dev process is broken, thus the bug. Is one developer terrible? Then the hiring criteria is badm thus the boss's fault. Are all developers making stupid mistakes due to lack of rest because they are working 12 hrs a day? Then the dev process is broken. As you can see 100% of the bugs are the fault of the boss.

As a side note: Every good development manager is aware of what I wrote above. And Agile strategies are meant to point out to the boss or his/her supperiors why dev is slowing down: Look, we're spending 50% of our time fixing bugs. Lets look at strategies to reduce them so we can spend 40% of the time fixing bugs, and then revisit this problem getting it to 30%. etc.

Unfortunately it sounds like you don't have a good manager because of the field. So I suggest doing (1) and not bringing it up to the manager (except on your exit interview)

share|improve this answer

Email him this SO question. If he's open to reason, the comments here will provide sanity checks for his reasoning. If he's not reasonable, you're unlikely to convince him with reasons that make sense. Additionally, he'll be able to read the reasons outside of a conversation (which can sometimes be more convincing because of the removed motivation to "be right" in the heat of a conversation).

You could also try to turn it around. The field could be "possible steps to avoid a similar bug from occurring", or something shorter to that effect. Then you could pool up solutions and vote on which ones to implement to make your workplace better. Perhaps a solution-oriented approach is more productive and likely better received (provided that there's actual follow through on the revisiting of suggestions).

share|improve this answer

Just let it go. Your boss will discover on his own that it causes a problem, if it does.

Lets be blunt, you have an opinion and so does he. He is your manager and his opinion is the one that wins.

Yes you can go to war over this issue, but is it really worth it? I doubt it lasts more than 3 months before it falls into disuse.

But actively sabotaging this or screaming about it just uses up political capital that is better saved for asking for that extra time off, next raise, promotion, or when a really critical design decision is going to be made.

At that moment, when it really counts you do npt want the boss to remember that you were the person who actively sabotaged his idea for "person to blame".

Respect the office even if you do not respect the decision.

Save the stress and table pounding for decisions that are going to be much longer lasting.

share|improve this answer
1  
That sort of people take politeness and sensibility for weakness. The next time he'll come with something much worse. And will be even less eager to listen to opinions. Even now he says that hurting people is fun. If you'll work together with such people you'll have to become a sadist, too, or a masochist. –  Gangnus Feb 21 at 14:15

It is strange that no one mentioned this before: Adding such a functionality to the bug tracker would motivate employees to try to game the system.

This is a common problem for approaches like what the question presented, among other similar ideas (paying by number of code lines, paying by number of bugs). This will encourage many to focus on getting a good score, instead of solving problems related to the software they are working on.

For example, trying to submit a bug report with a wording to lessen one's own blame, and shove it on someone else can lead to developers misunderstanding the cause of the problem (or the work being given to another developer who does not know that section of a code as good as the one who was working on it the most and who was the primary cause of the bug) leading to more time and effort to fix the problem.

share|improve this answer

Just make sure the first bug report in the system describes a bug in the bug reporting system called "person to blame" and put your boss's name in the person to blame field.

share|improve this answer
1  
This is funny but a great way to be fired. –  Ramhound Jul 5 '12 at 18:50

The root cause for a fielded defect is never a single person. Perfectly conscientious people will make errors, and a process that expects them to be infallible is unreasonable. If you are not verifying changes to production systems before deployment, either manually or through automated testing, then bugs are inevitable.

Wrong:

Bob forget to check input and the program crashed dividing by zero.

Right:

Code vulnerable to a divide by zero error was not detected before deployment. New test cases have been added to verify proper handling of invalid input. Code was corrected and all new test cases are passing.

share|improve this answer
5  
Even better: Coding guidelines/standards and code review checklists updated to avoid this happening again. –  Oddthinking Jun 29 '12 at 16:09
2  
@Adam: doesn't my answer directly address your exact question "What's wrong with blaming someone...?" –  kevin cline Oct 8 '12 at 21:27

I think your manager is trying to solve a problem with the wrong solution. I think maybe there is an issue that too many bugs are being released and your manager wants the developers to take more ownership and accountability towards the code that they write.

Using test driven development and setting up a continuous integration server (like Jenkins) will help to solve this problem, without introducing the "blame game". A continuous integration server is important to this because when someone commits code that "breaks the build" an email goes out to the team showing the person to blame. Since this code hasn't been released to a production environment, this type of blame is more proactive and encouraging (and fun!).

The result is that developers will take more ownership, feel more confident, and there will be less bugs in production code.

share|improve this answer

To give the boss some credit, the concept of "blame assignment" is already baked into tools like SVN, and appropriate use of the data can be constructive to developers in "finding out who to talk to" while debugging, e.g.: http://www.codinghorror.com/blog/2007/11/who-wrote-this-crap.html

While I agree with gnat's response above that a Root Cause field is a good thing, this isn't the same information, and "denormalizing" the field to sometimes assign the previous developer name(s) for the affected source, and sometimes have a technical description (e.g. "didn't scale to 10000 users") will just muddy the waters. I'd advocate for keeping a Root Cause field clearly a technical description (e.g. even when a clear programmer error, have it capture details such as "IndexOutOfRange Exception when fooData=999") This can potentially provide some useful feedback when reviewed en masse, and allow for some corrective actions to be taken to resolve entire classes of issues with architectural or framework changes (e.g. improving custom container classes, top-level exception handing)

That said, adding a Person To Blame field clearly can send a very bad message and destructive message to a software team that management wants to single out and punish individual developers who break code most often. I suspect manager believes that this public scrutiny will cause developers to be more careful and self-regulating to avoid getting their names on this "wall of shame", and doesn't understand why developers would feel threatened by this, especially if it is added generically to every bug report.

The problems with adding this as a bug field/potential metric are easy to start enumerating:

  1. Bugs are highly variable in difficulty to resolve, and a simple statistic of bug count/developer will not reflect this.
  2. Developers are highly variable in capability " " " " " " " " " " "
  3. Many software systems have components that need refactoring, however refactoring legacy components (particularly if the legacy base has no/limited unit testing facilities) will initially introduce bugs. Developers are likely to be discouraged from this "good" activity, if there's a stigma/fear associated with generating new bugs (even if these are trivial to resolve and the end result a major improvement in the system.)
  4. Testers may file a highly variable number of bugs related to the same issue, resulting in highly skewed bug counts/developer, unless a more detailed analysis is done.

That's just the tip of the iceberg. Combine these with the finger-pointing of who expected what API behavior, incorrect expected results in tests, and "earlier in the chain" issues with incorrect/missing requirements, and it should be obvious that a metric like this is doomed as valueless (unless the goal is to damage morale and cause a mass exodus.)

Back to the boss viewpoint, it's OK that he/she wants to find out if there are developers who are breaking code repeatedly, and to try and do something (hopefully constructive) about that. Trying to get this information by adding a field to bug reports is not going to provide meaningful information for the reasons listed above. In my experience, this information can be learned by being plugged in with the team, participating in most of the team meetings, integrating (carefully) information learned in occasional one-on-one meetings with team members, and getting familiar with the subsystems in the code (even if they can't read code.)

share|improve this answer

People don't go to work intent on making mistakes, and any strategy set in place, to specifically attach blame for what may or may not have been human error is ridiculous - not to mention extremely unprofessional.

At the very least, a "responsible party" assigned to take charge and "fix" the issue, or come up with a plan to track and/or prevent similar events from occurring, would be good. Sometimes the solution is nothing more than additional training. I've worked for a number of companies where it was part of your job description, to get a "company paid/company time" education. One place even built an entire "training center", that the local college "borrows" on occasion, for their industrial technologies courses.

I have worked in a manufacturing environment for the last 20 years, where programming mistakes don't just cause errors, they physically destroy things, and/or worse, they get people hurt. However, one constant in every field of manufacturing that stands strong, is that there is never, under any circumstances, someone to blame. Because it's a defect in the system, plain and simple - not a defect in the people. Look at it this way - the use of spell checker - a highly effective tool, for those less fortunate in the area of textual virtuosity, or maybe just those a little over worked... but by no means a method of blame or accountability.

A work environment, no matter what kind, or for what purpose it serves, is a system. A system made up of individual components, that if properly "in tune", works in total harmony - or some semblance of such.

Suggested reading on your boss' part: The 7 Habits of Highly Effective People

It sounds like he could use a little humility, if not a reality check. He's just as much a part of the team, as everyone else, and he needs to realize that - or it just won't work, and in the end, he will be holding the bag regardless.

Suggested reading and/or research on your part:

Look into 5 why analysis, root cause analysis... anything thing that puts you in a better position to offer a solution, not a problem. And your disagreement with your boss, is just that, a problem, not a solution. Offer him something better, something that makes sense, and even be prepared to allow him to take credit for the idea.

Right now it doesn't seem like he is prepared to fix anything, because he does not have a firm understanding of what is broken, if there is anything broken at all - other than his "I'm the boss" mentality.

Good Luck! I hope you manage to get through this, in a manner that's acceptable for all, especially in these times.

EDIT: Personally, from my own experience... "Go ahead, blame me. Because sure enough, I'll fix it, and down the road, when it happens again, who will be there to save the day? yep, you guessed it... me, with a big ole grin."

share|improve this answer

I once had a boss implement a system very similar to this, and although it wasn't programming (it was print design for a daily newspaper) the concept and appropriate response are the same.

What she did was instead of adding a 'person to blame' field on our paperwork she gave each of the designers a set of colored stickers. Each designer got a different colored sticker and was instructed that for any design worked on or even touched the sticker must be added to that design's paperwork.

The boss' stated goal for "the sticker initiative" was to establish the source of all our department's errors (mistakes in paperwork, misfilings, bad copy, essentially the print equivalent of bugs)

What we did was gave each of the other designers a quarter of our stickers so that we each had all the colors, and instead of putting just our color on each design we put all four of the designers' colors.

Don't just write your name in the [Blame] box- put everyone's name that is on the team/project, and make sure the whole team does the same.

We worked together against her orwellian bitchiness and as a result we actually ended up catching each others mistakes and talking to each other about it and ultimately had a significant reduction in errors. She was a sh*t manager though, and instead of recognizing that her initiative ended up uniting us and increasing productivity she got all butthurt and disbanded the sticker system and declared it a failure and formally reprimanded all of us.

share|improve this answer
1  
I am Spartacus! –  vsz Jun 30 '12 at 7:37
1  
+1 for being rude. :P –  Sarge Borsch Oct 6 '13 at 18:10

It will wind up punishing his most prolific programmer. Odds are, one or two people might be the best employees who have worked on the most projects. If you have, in a 10-person department, one coder who is just a fountain of output and he's written 60% of the interface code, then 60% of the bugs will be in his code.

Explain that this system would make it look like the person who writes the most code is the worst programmer, and the person who writes the least code is the best programmer.

share|improve this answer

If you're up for a little civil disobedience, get the team to agree to put a list of all the developers in that field for each bug. If that won't fit, write "I'm Spartacus!" instead. The point, of course, is that you're all responsible for all the bugs, and you're not happy about having to point out the individual who created any one bug.

Another option: play along. Don't do anything in particular -- just do good work and fill in the field as accurately as you can for a few months. Then explain to the boss that assigning blame for each bug makes everyone on the team unhappy and uncomfortable. Tell him that you all feel that there's little correlation between bugs created and anything else (skill, effort, sanity). (It'll help if you can run some numbers that show that there really isn't a correlation.)

Gandhian Civil Disobedience: Put your name on every field(unless other developers step up and put their name for their bugs), and accept blame for every bug whether it's yours or not. Nothing will render that field or the idea of blaming someone more useless than this. If your boss asks why is your name on every field, then you can explain "because I don't think development is a blame game, if you really need people to blame and crucify, then crucify me for everything and let my team work peacefully."

share|improve this answer
13  
I would upvote for the first paragraph, but the second one seems questionable to me. In my experience the kind of people who suggest ideas like a blame field in the first place aren't the kind of people who worry about making people uncomfortable. –  GordonM Jun 28 '12 at 20:14
3  
Additionally, the team still WILL suffer. All just to prove that boss was wrong? –  Oleg V. Volkov Jun 29 '12 at 11:53
23  
I'd always put the manager's name there. "In any organisation work sinks to the bottom, while responsibility floats to the top." –  David Schmitt Jun 29 '12 at 15:06
2  
@David: Both cream and scum float to the top. What are you dealing with in your organization? –  Donal Fellows Jun 30 '12 at 0:27

If you are doing Agile, and it sounds like you are from the features/stories comment. The person to blame would be the QA person that let the bug slip through, or the Product Owner / Customer that accepted the feature/story as complete with the bug in it.

I did typesetting back in the day, here is my take on it.

This is like blaming a typesetter for misspellings and other things that a proofreader should have found but missed. The typesetter made the misspelling, but the proofreader missed it, so it is the proofreader to blame for the mistake making to print, not the person that made the error in the first place.

In an Agile environment it is the QA persons responsibility to catch errors ( bugs ) and it is the Product Owners responsibility to not accept things that aren't correct. This is two levels of proof readers that should insulate the developers from things that get released, which is the only way anything should be classified as a bug in an Agile environment.

share|improve this answer
3  
To make matters worse, devs are now QA's, too. I know... –  MK_Dev Jun 29 '12 at 0:48
1  
Doing agile, the whole team is "the person to blame". Agile values team over individuals and it is the whole team developing the application, so every bug is the problem of the whole team. Think of the situation when a build fails on a CI server. The whole team should stop working and see if what needs to be done. At least this is what it should be! –  Sgoettschkes Jun 29 '12 at 14:47

Tell him "blame" is negative. Change it to "person to fix" then at least it is framed in a positive manner, and the same job still gets done. How can people work if they are being "blamed"?!

share|improve this answer

Change "Person to blame" to "Person to praise"

The main person to fix the bugs gets their name on it.

share|improve this answer
5  
I don't think this answers the question. It's a good sentiment, but doesn't provide arguments against such a field. –  Bryan Oakley Sep 17 '12 at 18:34
11  
Plus, you know one guy will introduce hundreds of bugs "accidentally" then fix them all, hoping some idiot manager will be dumb enough to think he's the best bug-fixer... –  MGOwen Mar 18 '13 at 4:25

It looks like your boss has not a deep understanding of software and maybe he does not intend to, either. So he has a different language, a different culture.

Quitting a job for a problem like this, before even trying to step forward for a solution is just being a quitter. Quitting is quitting. Do not quit until he makes you sure that you can never understand each other. To be sure about that, you should first try.

Since he does not know our language, and he is the boss, the first step here would be trying to talk to him in his language. What do I mean with language? Let's think together:

We software people, most of us love the job we do, we have a deep connection with what we are doing. Otherwise it does not work and one cannot go on in this business for a long time without loving it or being a complete ...you fill the blanks...

He, however, sees things much differently. With every bug report, while most of us get excited to make the thing work better (no, even if it is sometimes really very stressful, we love problems, just admit it!), he sees it as a failure, a measure of being unsuccessful. First thing he should want to understand is that bugs are good. Bugs makes clients love the company. (Now this is his language) When a customer reports a bug, or when we find one ourselves, after it is solved, it is much better than the situation it never happened. Bugs create customer loyalty (I am serious!), bugs create a great excuse to communication between the consumer and the producer of the software.

To "increase the profit of bugs" you should offer making bug reports even more open. With every bug report and its quick, clean, good solution, customers feel and see that "wow, these guys are awesome! They work really hard. Look at these things they are solving. We were not even aware that software was such a complex thing!" blah blah and blah...

Make your move, talk in his language. Bugs are great for a software company, not a problem. They make us a living.

For team ethics, efficiency, or any kind of talk you would make might work the opposite way you intended. If you want to quit, he will think "aha, my solution started to work from the very first day! Bad links have already started to drop by themselves before they are exposed!" He believes in his idea of finding the bad boys in the company and it is very difficult to convince him otherwise. Especially when you might be one of those bad boys!

So, focus on his real problem: Bugs. Show him that bugs can be very useful. Without any problems, a relationship is boring. Everything that does not kill you makes you stronger. Every bug is a great opportunity that you can use to increase the customer happiness.

This is just one thing you can tell. Think about his concerns and you will find many other items to add to your list. The GOLDEN KEY is to offer an alternative thing instead of fighting with his idea!

share|improve this answer
1  
I really cannot believe someone just down voted my answer the next second I saw it here? Is there some system that I am not aware? –  hasanyasin Jun 29 '12 at 1:05
3  
Not the downvoter, but the question explicitly said there were multiple attempts made to convince the boss it was a bad idea, so the second paragraph of your answer wasn't appropriate. –  Larry Coleman Jun 29 '12 at 13:28
5  
I very much disagree with the notion that there's anything wrong with quitting a job when the company is doing things is a dumb way. It is not your problem to fix the company. If my quitting confirms the boss's own logic in his eyes, that's his problem; it stopped being mine the moment I walked out the door. –  Nate C-K Jul 1 '12 at 19:07

There are at least three problems with that field.

The first one is that blaming people isn't good for morale. Ok. But maybe he doesn't care about morale and wants to fire bad developers. Hard to argue against.

The second one is that getting that field right is going to be hard and a pretty big time sink. It's more complex than just finding out who wrote the bad code. And any potentially information that is hard to figure out can be sandbagged/cheated on. But maybe he's prepared to pay that cost and audit the information. Fine.

The more fundamental issue is that this field is not going to be a good metric to take action on. Sure, he'll have a nice ranking of whose code causes the most defects. But guess who'll be on top of that list? Probably the company founder, or maybe a top developer who has a very low defect rate but is so productive he writes a disproportionate portion of the code. So he'll either end up firing his best developer, or have him slow down so much he's not his best developer any more. And they guy who writes a line of code a month - preferably comments - will probably get rewarded for his low defect numbers.

Yet another software metric failure.

share|improve this answer
9  
I'm surprised nobody else has mentioned the fact that analyzing the history of an error in attempts to assign blame is going to be a huge time sink. If no other arguments bite, that should. –  Michael Kjörling Jun 29 '12 at 7:42
2  
+1 for para three. I once worked with a dev who wrote dozens of lines of code... in six months. We never did find a bug in his code, though! (We were not working for NASA nor programming nuclear reactor controllers). –  Jon of All Trades Jun 29 '12 at 22:59

This field will not fix the current issue/bug.It causes more effort. More time equals more costs.Less money for the boss.

Perhaps a revision for your "Definition of Done (DoD)" will help to consider a better quality in your process.

share|improve this answer

Your actual question was about how to change the culture before you leave the company, by convincing your boss that adding a person to blame field for bug reports is a bad idea. But of course changing the culture requires him to really understand why this is a bad idea.

This is a tall order. Besides the issue of saving face after changing his mind, there is the basic problem that people who think about solutions primarily in terms of individual blame are usually pretty set in that mindset.

You asked for writing on this topic, and Peopleware comes to mind. It's highly regarded and talks in general terms about how to manage people doing creative work where the output is difficult to measure. The problem is that you reading it won't help much, your boss would have to read it, and believe at least some of it.

Oddly, since the problem here is more about people than bug reports, it very possibly belongs more on Workplace than Programmers. But the success of software projects is usually pretty heavily traceable to human social interaction, so the real answers are often mostly about things that transcend software.

My only other, half serious, suggestion is to say (or convince a co-worker to say, since you plan to leave) that you are willing to take on full responsibility for the project's success, and your name should always go in the field, since even if someone else made the mistake directly, you have assumed responsibility for making sure everyone on the team does quality work.

It's nonsense of course, how could you ever back that up, but some people (especially people who are big on blame) really eat that stuff up. Ronald Reagan used to publicly accept personal responsibility every time any member of his administration was caught in a scandal (and there were quite a few) and it actually worked out pretty well politically every time. The best part for you is that the responsibility generally comes with no actual consequences, they just think you are a stand up guy for taking the responsibility.

Or maybe that's not how it will go down. It makes no sense at all to me so it's hard for me to predict when it will work, but I have witnessed it work when it seemed to have no business doing so (in the workplace, not just the Reagan example).

share|improve this answer

Another probable result for such a policy is that people won't report bug if they think they may be the "person to blame", so it will actually reduce the number of bug reported by the team.

share|improve this answer
206  
Well, the boss will be happy! There'll be fewer bug reports, and therefore, the quality must have gone up. –  nicodemus13 Jun 28 '12 at 21:27
77  
@nicodemus13 Your logic is flawless –  Laurent Parenteau Jun 28 '12 at 22:35
4  
The boss is probably on performance related pay and one key performance indicator is the number of bugs reported. Hopefully he/she will share out his bonus to the development team at the end of the year. –  Matt Wilko Jun 29 '12 at 12:35
11  
@nicodemus13 You've got a future in project management ahead of you, sir! ;) –  Jon Ownbey Jun 29 '12 at 13:02
28  
From experience, this is not a "probable" result, it's 100% absolutely certain that this will happen, because developers are smart people. What you will also see is a massive increase time spent arguing violently with testers that their "bugs" aren't bugs. –  Joris Timmermans Jun 29 '12 at 13:50

Tell your boss that developing in a team needs social skills. He might even nod.

But the problem is, that this is something developers are extremely bad with. Adding tools that suggest blaming is more important than proper problem analysis is counter-productive.

Instead you need incentives to improve social skills, and the communication infrastructure you have should support that. For example, coin it positively: Name a person who is responsible for a ticket, who takes care of it.

Also start with code reviews so you can learn from each other. That spares the blames later on.

share|improve this answer

Simple answer.

The "Blame" field will be used for nothing more than scapegoating and fingerpointing, morale will plummet, team trust will be destroyed and everyone will be trying to find ways to prove that something is not their fault instead of fixing it. People will also be more inclined to keep quiet about bugs instead of reporting them, because they don't want a colleague to get into trouble. It's completely counter productive.

What's more important, victimising somebody for making an honest mistake, or getting the problem fixed as quickly as possible?

Your boss seems to think bugs are a sign of laziness or sloppiness. They're not. They're a fact of life. How many patches does Microsoft push out in a year?

share|improve this answer
4  
+1, a culture of blame always leads to a culture of keeping quiet about bugs and hoping nobody else notices –  Carson63000 Dec 16 '12 at 19:52

The main argument I would use against it is to ask what problem he's trying to solve. There are almost certainly better ways of solving the same problem.

For one thing, is there really only ever one person to blame? If there is, you're doing something else wrong. A good process takes a piece of work through an analyst, a programmer, a reviewer and a tester before it gets to production. If you're not doing all of these stages, maybe that's the solution to the problem your boss is trying to solve. If you are then which one is to blame? It might be none of them, it could be legacy code that's to blame.

It's no good having people back-biting and pointing fingers, trying to avoid a black mark which won't go away once it's set. It solves nothing. Very few people are maliciously negligent. You need to do a proper retrospective, see what went wrong and what you can do to make sure it doesn't go wrong again.

From that you will clearly see if one person is regularly at fault and that may be a different problem to deal with.

The trick to stopping a manager set on creating accountability is to offer it freely, but in a way that actually makes sense to you.

share|improve this answer
3  
A really good process avoids the analyst and the programmer to be two different persons - my experiences with analysts who cannot program and programmers who cannot analyse were really bad. Nevertheless, +1 for your answer. –  Doc Brown Jun 28 '12 at 20:18
3  
This book will help you find the words to stand your ground amazon.com/The-Power-Positive-No-Relationship/dp/0553384260/… –  zundarz Jun 28 '12 at 21:05

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.