Coding with Two Sets of Eyes (Part 1)

How pair programming can increase software quality

Defining software quality is kind of like defining beauty — “it depends.”

Most people involved with developing software agree that “high-quality” means creating a system that does what it’s supposed to do without any strange side effects, and provides an experience that users rave about.

But how do you get there?

One option is to hire a phalanx of testers to check stuff after you’re done coding. That’s not a bad strategy. Testing after the fact certainly catches code bugs and glitches in the user experience. We recommend testing, even testing after the fact.

But there is a smarter strategy that helps you catch problems before testers ever put your software through its paces. This strategy saves time and money. We call it “two sets of eyes.” In a nutshell, it means to have at least two people look at the code to make sure it:

• is as simple as possible to get the job done;
• includes tests and passes them all;
• delivers on what it’s supposed to; and
• clearly expresses to a competent developer what it is trying to do.

It’s not rocket science. It’s more about discipline than super-human intelligence. And more than that, it’s a conversation about the code. The code that one person writes may work fine, but having a conversation about the code early in the development process often refines the system’s design. This process adds a nice layer of accountability too, encouraging the delivery of complete features (well written code, tests, documentation, etc.).

Code tends to be less than it could be when only one person looks at it. It’s often more complex than necessary. It’s often buggy. It’s often shortsighted. It may seem perfectly clear to the person who wrote it, but not so clear for the first person that reads it. Software code is read far more than it’s written.

We never release code “into the wild” unless more than one person has looked at it. (Okay, we do it sometimes in very rare cases). We are craftsmen. We take pride in our work, and our work is our best advertisement. Even if the only reason to use two sets of eyes was to increase confidence in what we create, we would embrace the practice. We simply won’t compromise on the two sets of eyes element of our craftsmanship. That goes for the software we make for ourselves and we produce for our customers.

We follow the two sets of eyes rule because it reduces business risk. Fixing bugs, or correcting misses in whatever form they take, is easier and cheaper the earlier it is done. We like to fix bugs as close to the act of writing the code as we practically can.

We also have good business sense and have found that code analyzed by two sets of eyes is very likely to cost less. It sometimes costs less to create (although that’s very hard to confirm), and it almost always costs less over time for these reasons:

• The code is better factored, so it’s easier to change (and what system doesn’t need to change over time?).
• The code is better tested, which means we can change it more confidently, knowing that we didn’t break anything in our system.
• More people on the team are familiar with the code, which means our risk of losing the “one person” on the team who understands the code drops significantly.
• Having a second set of eyes guarantees at least one other person on the team can read what the writer wrote and intended.

Regardless of the approach, having two sets of eyes on all code we write helps us reduce business risk, reduce system cost, and be more agile as systems we create change over time. Everybody wins.

That’s why we recommend this practice to customers and colleagues.

In two weeks, we’ll continue this 3 part series by discussing the forms that two sets of eyes can take, and why we prefer some forms over others.