Sometimes it seems to me that people ask for code-reviews just so they would be able to say "Xyz reviewed my code!"(1) when something broke.

Question, is that ever the case? (Or is it just my imagination) If it is, how do I handle this?

(1): What s/he really meant: It's Xyz's fault or something along those lines.


If the first thing a developer thinks when their code fails is shifting the blame, it sounds like a broader cultural issue. Does the developer feel too attached to their code and so is their ego to blame? Is the developer inexperienced or feel they have something to prove?

Alternatively, does management yell at developers for defects and say nothing when things work? Is the team under pressure to shed headcount? Are developers uncomfortable with technologies and processes? When developers are told to fix an issue, do they feel they are blamed?

Everyone makes mistakes. The best software developers admit it, learn from it and move on. However, if a single mistake from a single person is enough to cause a large problem, this is a wider system problem and the responsibility of management.

Assuming none of these are the problem and returning to code reviews, code reviews are about a lot more than finding bugs. For example, it is knowledge sharing, ensuring code style is consistent, ensuring unit tests are done and documentation is up to date.

The best code reviews are two way discussions between the reviewers and authors and are soon reciprocated with the reviewers code. If the developers enjoy it and get value out of it, blame will not occur. The responsibility for quality code rests with the team and not Xyz.


The only way to do it is to move away from a perception of code review as a "review" of what someone did, to an information-passing system. So instead of the reviewer driving the review and critiquing the developer's code, the developer drives the review to teach the reviewer what (and why) he did.

Ultimately the same result is achieved, but in a way that has far less negative connotations.


You may like an Agile practice called "The Perfection Game", wich is part of the Core Protocols.

Summarily this is how it works:

  • the programmer ask to some potential reviewer if he is OK to play a perfection game
  • if reviewer is OK, the reviewer check the code an give a value of 1 to 10, depending on the value he believe can add to the code (for instance if he says 1 it may mean either this is a piece of shit but I do not understand a bit of it, won't be of any help, or it can mean this is nearly perfect, I couldn't do better. If reviewer says 10 on the other hand it would mean: your code is a piece of crap, but you have luck : I can help you with that because I'm an expert of this kind of crap).
  • the reviewer explains what he likes (not what he dislikes) in the reviewed code
  • the programmer then ask what would be needed to make that code perfect and the reviewer explains it.
  • the programmer then thanks the reviewer and change his code if necessary.

Of course this can be iterated until the programmer stops looking for perfection, or the reviewer can't help any more (he will give a low evaluation and the programmer will stop there).

This is a bit formal as it comes from Core Protocols, but the programmer is always responsible of the code changes and is asking review as a service. He usually won't use this kind of review to reject responsibility, on the contrary the programmer should ask to another reviewer if a given one won't be able to help.

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