'''Terminology'''

The term ''peer review'' comes from academic publishing.  It has been one of the CodeReviewPatterns for about 25 years.

'''Context'''

Egotism and urgency make it hard for a person to see their own errors, so it pays to get someone else to look at what you are doing. However, most people will hide their mistakes from their manager or anyone else higher in the organization.

'''Resolution'''

Reviewers should be at the same level in the organization as the person who did the work.

There are some possible variations:
	* The work is reviewed anonymously.
	* The work gets an EditHint by a signing FriendlyPeerContributor.
	* You write it and I'll comment on it. I write the checks, and you check my writing.
	* The person with problem leaves office and talks at the first person they meet in the corridor who has to ask at regular intervals "why". Surprisingly good at finding errors. See CardboardProgrammer.
	* Someone is appointed by management to go through your code in your workplace.
	* Managers may '''not''' attend CodeInspections, CodeWalkthrough''''''s, DesignReview''''''s, etc etc.

'''Alternatives'''

PairProgramming is designed to be as effective as PeerReview but faster and more fun.  See CodeReviewPatterns.
-----
I think both methods can be seen orthogonal to each other, i.e. they can work in tandem. A special case of PeerReview is giving EditHint''''''s as done by a FriendlyPeerContributor.
----
Contributors: DickBotting, FridemarPache
----
One must accept the initial premise, however.  If I take the statement that "The person involved with a task is less likely to be aware of the problems of the task" and replace it with the equivalent statement, "A person uninvolved with a task is more likely to detect problems with the task" one can see the fatal flaw with software peer reviews.

To be able to detect errors, one must be intimately familiar with the problem to be addressed.  No one in a peer review has done the level of investigation of the problem to be solved that the code developer has done.  It is not reasonable to expect another person to come in, spend only a tiny fraction of the time, and become a higher level authority to review the software.  This leads to the reality in software peer reviews, a combination of apathy and petty bickering over trivialities.

Another observation that has been raised by some, is that reviews in general tend to decrease quality and as the number of reviewers increase, the quality continues to decrease.  Why?  Divided responsibilities.  If the reviewer is "responsible" for finding errors, then the developer does not need to spend the time ensuring correctness.  However, if the developer is "responsible" for writing correct code, then the reviewer does not need to spend the time finding mistakes.  If there are multiple reviewers, each can rely on the others to detect what he has missed, resulting in none finding anything.

Peer reviews of software are simply not worth the effort.  The responsibility for correct code cannot be handed off to reviewers, but must be planned for ahead of time.