There is a SoftwareDevelopment principle that states, "Any significant modification to the system should be reviewed by AtLeastTwoReviewers."
Interesting. I've worked at several banks and they don't send money out of the bank (wire transfer etc.) unless the transaction has AtLeastTwoReviewers. This is related to another "accepted practice" of MakerChecker. -- ShalomReich
I've read that four people (including the author) are twice as effective as three. This fits my experience. -- JeremyCromwell
I've read that additional reviewers are less effective. As the number of reviewers increase, there is the tendency to be less thorough and expect others to find problems. When one reviewer finds a problem, there is the tendency to ignore it if others did not also report the problem. This is one of the major arguments in favor of error prevention rather than error detection via testing and review. Review is not a very effective way to detect problems and adding reviewers makes it less effective.
- On the contrary, WattsHumphrey ("ManagingTheSoftwareProcess", pp. 186-187) and SteveMcConnell ("RapidDevelopment", pp. 73-75) cite numerous examples/studies, which suggest reviews are very effective at detecting errors.
- If you assign a review to a number of referees and tell them they are just one of n, then this is probably true. If you assign refereees one at a time, and are conscious of what special expertise you think each referee will contribute, then this is probably not true -- CharlesStewart
Sounds a bit like PairProgramming ( and like working the DriveThru at McDonalds ). -- ErikMeade
I've heard that it's called FourEyesPrinciple in banking. -- SavasAlparslan
Also see CodeReviewPatterns.