In Favor of Pairing

There aren’t many controlled studies about software development techniques, but the few that exist suggest that the single most effective way to ensure quality is built in is to have code reviews. Indications are that multiple reviewers don’t add value; a single reviewer is sufficient. In addition, after about one hour the reviewer’s mind gets tired and he/she starts to overlook things.

With those points in mind, we often recommend the following:

• Keep units of source code small – small classes, modules, functions, methods, etc. Small units are easier to read and understand, easier to compose into larger solutions, easier to keep in compliance with general software design guidelines, and of course easier to review without missing something.
• Work in pairs to develop code – this makes code review continuous, so that we don’t create a bottleneck for an after-the-fact formal code review “step” in our delivery process. (The mobbing approach also supports this factor, although it isn’t the only or primary value of mobbing.)
• Check in code frequently and in small increments – this helps keep the pieces small enough to be reviewed steadily and usefully, as well as other benefits such as making it feasible to run tests frequently and get rapid feedback from the build.

You’ll recognize all those techniques as adding value in other ways besides continuous code review, as well. Pairing isn’t the only way to help ensure high quality, but it may be the easiest technique to put into practice. Other techniques, such as test-driven development, refactoring monolithic code, or continuous integration may be more challenging to learn. Pairing is a relatively easy place to start.

Pairing enables code review without creating a bottleneck. It thus supports the current emphasis in software development on both Lean and Agile thinking. The cost is low – the time to produce the same number of lines of source code is about the same or just slightly greater, while the time to get to “done” is almost always far shorter, owing to the numerous small errors that are avoided by having a second pair of eyes (usually connected to a second brain) actively engaged in the development process.