What about code reviews?

The fallow pattern is intended to complement, rather than replace code reviews, which are an essential part of the programming process. Rather, it is intended to enforce conceptual integrity, good design decisions and best practices during the implementation process. In contrast, code reviews are:

Furthermore, code reviews come in two flavours: before and after a merge. The former case is a terrific source for a productivity bottleneck, and in the latter case, any damage to the project's conceptual integrity is all but irrevocably done: I have yet to meet a software project manager who, with a schedule to keep, would green-light the rewrite of a component that worked, no matter how baroque, inefficient or ugly it was.

What about pair programming?

Agile and specifically XP proponents will immediately recognize this pattern as serving the same primary function as pair programming. My contention is that not only does the fallow pattern achieve the same goal as pair programming, it lacks the significant drawbacks of pairing, such as:

Albeit the intent behind pair programming is perfectly noble, its all-or-nothing disposition yields diminishing returns. I know there have been studies that report mediocre productivity gains through pairing, but I have my doubts about their applicability to real-world situations. The fallow pattern can in some ways be compared to a sort of Pairing Lite™, insofar as one programmer observes another and offers insight, just not all the time.

Furthermore, it should be noted that those aforementioned trivial issues are certainly important for the conceptual integrity of the project, but are much better off being tackled in larger swaths, such as just after a visit from a fallow programmer.

So then, how does one go about implementing this strategy?