For reasons I’ve mentioned before, I think that at some point during the project, when things are fairly well understood, developers should work individually. On a recently completed project, our early efforts were almost exclusively pair programming. In the later stages of the project, we split up and worked individually.
During deployment, we encountered several errors, all of which were related to stored procs developed after pair programming stopped. The errors were all easy to fix once the offending proc was found (it took longer than normal since our project was a data warehouse reporting solution crunching gigabytes o' data). In helping to debug these errors, I noticed I could easily have spotted them before deployment, when you want things to run very smoothly and not have to deal with minor issues.
Code reviews in this case would really have helped, and will certainly be part of future projects for any individually developed code. Reviewing the stored proc would have taken about 5 minutes. That 5 minutes spent earlier in the development cycle is much better than 30 minutes later in the cycle (especially during deployment!).
But why not pair program the entire time? For this project, the majority of the time spent was in understanding the domain around the requirement. The time it took to figure that out dwarfed the time it took to write the stored proc. However, it was in the writing of the stored proc where the error was introduced. So the easiest and quickest way to fix that is to introduce a set of “fresh eyes” to look over the writing portion.
The fresh eyes test is the key to why I think code reviews are still important, even if a team is pair programming. Two programmers, even if one is thinking strategically and one tactically, might still miss the forest for the trees. In a previous project, our team did pair design followed by peer review. For the parts of the project that were done this way, very little was ever found to be fundamentally flawed. Code reviews in that project also took very little time and caught a lot of omission errors (one of the hardest types of errors to catch).
Michael Hamman explains, in a blog dissertation on cognitive breakdowns, the exact reason why I think pair programming teams need to stop and have their work reviewed by an external party (external meaning anyone other than the two members of the pair):
Because sometimes our flow needs to be broken—we need to be awoken from our “circumspective” slumber. [Breakdown, Not a Problem]
There are several important characteristics to the code reviews that I promote. First, they need to be informal. Formal tracking, review by a panel of other developers and a facilitator, etc. is just too much for most agile projects. Second, the reviews need to cover all non-pair-programmed code. This is the absolute minimum, with more to be added as you see fit. I also code review (or peer review, whatever sounds better to you) anything that has been pair-designed, because these are usually the key parts of the system. Third, the reviews should be relatively quick, and the turnaround time should be quick as well. Simply pick a time once, twice, or three times per week (whatever works for your team) and do it. 30 minutes has always been plenty of (if not too much) time. And the changes are made immediately.
That’s about it. The overall quality of the code will go up as bugs are reduced. Fewer bugs mean a more predictable schedule. Both of these make customers happier, which is vitally important as a consultant in the current IT environment.