Two Sets Of Eyes

This is a less extreme version of PairProgramming which we use when we can't possibly be programming in pairs (and some other less disciplined moments). The basic rule is that you can write production code by yourself if you have permission ahead of time (like at a StandUpMeeting where it was recognized that we had an odd number of people and we were all ready to tackle real stuff), but it can not get integrated until another person has reviewed it. Typically, this means that the other person will want to drive and RefactorMercilessly before they OK it. But, there are many occasions where the code consists of only a few clean methods and the 2nd developer signs it off. These programming alone sessions shouldn't last very long... see TwoPairsWithThreePeople.

The more extreme practice would be throw it out and rewrite it. Some would argue that this is always better. We've found that when TwoSetsOfEyes are used by disciplined teams, the results are just fine and there is no real benefit in writing the code over... especially in the case where the original author is not a fast programmer.

Note that I do not claim this is as good as PairProgramming, only that it accomplishes many of the same goals, though not as effectively. We would never choose it over PairProgramming, we only use it when circumstances warrant. For example, last week two of us were at a client site for 3 days, one was left behind working on a sticky problem. The one left behind had a bunch of scratch code, several tests, and 4-5 production methods when we returned. The 4-5 production methods were fine, needing only a minor change. The tests I had to RefactorMercilessly in order to figure out what they were trying to do as well as help the other programmer (summer intern) learn a couple of refactoring techniques and better practices. -- KenAuer

This sounds exactly like the kind of InformalReviews that RobertMartin says his group uses at ObjectMentor. BradAppleton mentioned this in IssuesOnReviews and the eXPerts seemed pretty adamant against even InformalReviews (see ExtremeReviews and also ExtremeProgrammingCodeReviews).

Boy, after reading the pointers, I don't see how it sounds exactly the same at all. Maybe I need to rewrite mine. Bottom line is (to me), we'd rather never do TwoSetsOfEyes vs. PairProgramming. Fact is, we don't always have a reasonable option and this is the next best thing we've found. It ain't better or even close to as good! -- KenAuer

I said nothing at all about "better or close" to PairProgramming. I dont want to see another heated debate come out of it when it wasnt the issue or the question being posed.

Look at InformalReviews again and the description of how RobertMartin's shop practices it and then please tell me the specific details where you think it differs from TwoSetsOfEyes. To me these two practices look 'exactly' the same! You simply have a buddy quickly look over your code and discuss any issues/corrections with you soon as conveniently possible. What is the difference here?

I think their is a completely different set of assumptions working on InformalReviews (which has been declared an XP-Free zone... TwoSetsOfEyes is not). With TwoSetsOfEyes, you do not "simply have a buddy quickly look over your code...". We don't have everybody working in TwoSetsOfEyes mode... in fact, we never (at least not on purpose) have more than one person working in this mode at a time. We get in this mode because either:

If that's not enough to explain why they aren't 'exactly' the same, I'll be explicit as to the differences...

  1. You must first have permission to work on the code by yourself. It is clear to all that PairProgramming is better, it just isn't practical 'for the moment' and there has been enough discussion about the task at hand that what's left to do is little more than typing in the code. As Martin Fowler and others have said (paraphrased), "PairProgramming would be terribly inefficient if the most important part of programming was typing". TwoSetsOfEyes is most acceptable (maybe even ideal) when typing is just about all that's left to do... of course that's hardly ever the case. It is marginally acceptable when typing is the majority of what's left to do.
  2. According to the InformalReviews page, no more than 5% of an engineers time can be in meetings, reviews, etc. The rest of the page seems to imply that PairProgramming would be a form of review which needs to be avoided. I'm OK with the 5% of the time in formal meetings, etc. but do not consider PairProgramming or being the second set of eyes something that falls into this category of overhead. 'Every line' of production code should be looked at... a small amount of it (like getters and setters) barely gets a glance, but everything else is gone over in detail.
  3. No one subjectively determines what is "critical"... every line of code that goes into the product is critical. Every line needs to have TwoSetsOfEyes.
  4. The length of time where someone programs alone is a different scale. There is no ideal length of time other than zero. The acceptable, practical length of time on production code is typically measured in hours or minutes. (They can spend more on scratch code and test code as in the summer intern example above). The rule of thumb is that it should take no more than 5 minutes for the first pass by the second set of eyes, typically much less. Once the first pass occurs, the amount of rework could be anywhere from zero to an hour or two.
  5. It doesn't get reviewed "when somebody gets around to it". It is of the highest priority to have it reviewed as soon as humanly possible. It is of the same priority as working with another pair... therefore, as soon as a person can break from another pair to review it (or as soon as they get back from the bathroom or some other high priority interruption) they must! The code being reviewed is still fresh in the author's mind and the context in which it was written is still fresh in the reviewer's mind.
  6. When the "5 minutes for the first pass" rule is broken, their is something that absolutely needs to be corrected... I won't go into all the possibilities of what's wrong or how to fix it here. I'll just assert vehemently that it needs to be fixed. This is part of XP... when you get feedback that things aren't working, you must fix them.

Regardless of whether you are advocating TwoSetsOfEyes in addition to PairProgramming, or as a next best thing if you cant do PairProgramming, it still seemed to me like the eXPerts were dissatisfied with InformalReviews on its own merits. Are you saying there should be an exception for when it is too hard to achieve PairProgramming? If so, why would that be preferable over trying to move heaven and earth to do PairProgramming by hook or by crook (IOW - is the answer really TwoSetsOfEyes or is it to step back and reaffirm that it must be PairProgramming, no exceptions, and if it doesnt look like it can be done than a way must still be found/created)? If TwoSetsOfEyes really is the best fit for this undesirably constrained situation, then in the absence of PairProgramming, why would TwoSetsOfEyes be preferable to other methods of review or inspection discussed here on the Wiki, for cases when PairProgramming is deemed "not a feasible option"?

I think the confusion stems from the misperception that we are advocating giving in on PairProgramming and settling for TwoSetsOfEyes. No, PairProgramming is the rule and TwoSetsOfEyes is the exception handler. When we started the project, we didn't know how many exceptions we were going to have to handle and wanted to assert that we were reasonable people about PairProgramming because we had a way to handle exceptions... pushing even the exception of TwoSetsOfEyes is viewed radical in many places. We were trying to diffuse the resistance to PairProgramming that we've gotten just about anywhere we've introduced the concept by making it OK to try without having to make a long-term commitment. We were expecting PairProgramming to prove itself if given a chance, but were rather shocked at how quickly it succeeded in doing so. Much of this is due to the personality of the team members. I wouldn't expect it to happen so quickly with a different set of individuals. In fact, I've seen it be dissed with a different set of individuals.

If you are not doing PairProgramming at all, you are missing out big time. There are a lot of methods you can try to get some of the benefits of PairProgramming. I've used a lot of them myself over the years, and much of them are improvements over the status quo in most places. Pick whichever one works best for you, but if you are not totally prevented from doing PairProgramming, do it.

I think all of the above answers the questions posed. But just in case it doesn't...

The goal shouldn't be to do PairProgramming every moment of every day. It isn't worth making people take pee-pee breaks at the same time (although it is often convenient when you can). It's missing the point to make sure somebody watches you type in a getter method that both of you know belongs in the code. The goal of PairProgramming (along with other XP practices) is to achieve the best way to produce quality code at a high and sustained velocity over an extended period of time that is not dependent on an individual to keep it at that quality. Is it the best way at every point in time given that moment's constraints in reality? Absolutely not! (NOTE: The author still asserts that it is the best way he's seen over an extended period of time where extended means greater than an hour or two).

XP is a process that celebrates the unique ability of humans to reason. Reasonable people who have experienced the benefits of PairProgramming should be able to discern those moments when it is not the best way and not be frozen during those moments. I'd even go so far as to say we should exploit those moments to achieve a slightly higher level of productivity by getting TwoPairsWithThreePeople or simply not stopping when a partner gets pulled away as long as we realize they are moments of exception rather than the norm. We refuse to let an odd number of people or a pee-pee break keep us from being productive or completely sucking us "out of the flow". We still believe that PairProgramming is the best way to produce quality code at a high and sustained velocity over an extended period of time that is not dependent on an individual to keep it at that quality. TwoSetsOfEyes and PairProgramming aren't mutually exclusive nor are they alternative approaches. TwoSetsOfEyes is an exception handling process on PairProgramming that should be used whenever it is wise to do so, but no more than that! If you are getting feedback that it's being overused, cut back on it or eliminate it until you can use it wisely.

One last note. I think the number of moments when PairProgramming is not the best way is slightly higher in Java than in Smalltalk. In Smalltalk, there aren't all of those little compiler errors you have to get out before you move on... especially not when you are using Refactory. When we use VisualAge for Java, there are many times that we delete a method or alter a method signature and get a bunch of little red X's. Often they are expected and both members of the pair know exactly how to change each corresponding method/class to fix them. The value of the pair during the time it takes to get rid of them is suspect. A decent RefactoringTool? would change this reality. --KenAuer

A sceptical view of motivation

One of the possible reasons that it a requirement that there be "TwoSetsOfEyes", involved in the lack of confidence in the "first" set of eyes, that has accepted the challenge of producing an artifact (often one nobody else wanted to attempt) and has furnished a working model which could be released. Those who did not originally think it was a politically appropriate challenge because they didn't think it was possible in the expected time frame because of the "high visibility" or that to accept and not produce might be a career ending move, who now see a "newbee" not only accept, but also produce a product. Because of their "inside" connections, certain backstage efforts to invoke "Two sets of eyes" to permit and allow the diverting of "credit for the deed" from the one who did all the hard work to the one assigned to "look it over", allowing one to receive credit for the work when the review is done and the work is accepted, without the risk on the part of the reviewer of failure. Often the first set of eyes is a contractor, and the second set of eyes is a "company man". The contractor then might move on to greener pastures and the only one left to share and "claim" credit is (guess who!) the company man.

EditText of this page (last edited January 11, 2008) or FindPage with title or text search