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:

• Asynchronous, often with the original programmer in absentia,
• Antagonistic, and
• Oriented toward discrete implementation flaws.

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:

• Before you adopt pair programming en masse, you often need to invest in additional hardware and/or use special code editing software;
• If you're the driver, you incur the frustration of someone constantly nagging you over trivial issues, or worse, dictating code;
• If you're the navigator, you incur the frustration of not being able to just type out the code yourself;
• If you're remote-pairing, you will eventually end up fighting over the same code block, if you aren't already fighting for control of the cursor;
• The path of least resistance degrades to bickering over such issues as the naming of variables, coding style and semantically equivalent constructs.

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?