Continuous Review

Normal reviews are done after the event and look for problems in the code.

Continuous Review is done as the code is written.

Continuous Review looks for problems but it also looks for opportunities to improve the code. PostHocReview?s cannot in general suggest improvements because the code is supposed to be finished. Only actual problems justify rework.

Continuous Review allows comments to be addressed before being fully implemented. Because Continuous Review exposes problems to two brains it produces better code faster than a lone programmer would.

Evidence collected to date suggests that Continuous Review is not quite twice as fast as using a lone programmer. This suggests that although it saves on elapsed time, it increases effort. However, it is more effective at preventing problems and so may be cheaper over the life of a project.

Continuous Review has the added benefit of transferring knowledge between the coder and the reviewer. Continuous review is very effective at aligning developer style and technique.

Is ContinuousReview just a synonym of PairProgramming?

Probably. Except that it doesn't assume CollectiveCodeOwnership or any other XP practices.