Two are better than one

“If you can't explain it to a six year old, 

you don't understand it yourself.”

― Albert Einstein

Pair programming is uncomfortable, exhausting, and un-ergonomic. With pairing it takes two or more people to do a job of one. It is time-consuming to organize, tiring to participate in, and painstakingly slow to observe. The benefits are non-obvious.

Code reviews are nerve-wrecking, aggravating, and painful. They take enormous amounts of time, bring out the worst attitudes, and spur religious wars on code minutiae. Results are often inconsistent, suggestions are petty, and resulting improvement is invisible.

Yet, there is plenty of evidence that teams that manage through the pain and find the time to pair, to review, to swarm, to mob-program, and to work together using any other technique, do significantly better. Pairing and code reviews contribute greatly to the value being delivered in higher product quality, shorter time to release, and in lower maintenance costs.

It comes down to a simple truth, noted a long time ago:

“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.” - Brian W. Kernighan and P. J. Plauger

 Left to our own devices, we want to be clever. But if we have to explain every turn of logic, every leap of faith, and every tiny assumption to another human, the desire for cleverness retires to the back of our minds, and leaves the center stage for the desire to be understood. This difference alone causes a big improvement in the work that we produce. Readable code has a much better chance of being good code, than code that’s hard to read.

It also means that the person reviewing the code, or being the non-writer in the pair does not have to be a developer, she could be anyone familiar with the product.  Even if that person does not contribute directly to the code, their questions will influence the programmer to write better software.

In the case of two or more developers working together, in addition to producing better code, all involved will be intensely learning from each other. And that’s the best thing that could possibly happen to developers.

[It will also make them tired.  I suggest getting a lot of colorful plastic balls, and investing in the fanciest espresso machine your office can afford.]