This page discusses PairProgramming, when one member of the pair is GrandMasterProgrammer.
It is inspired by comments on these pages: XpIsGeniusFriendly and PairProgrammingEconomics
The paragraphs below use the terms "genius" and GrandMasterProgrammer interchangeably.
My key concern is this: a genius sees potential solutions that others don't. So, what happens when you're pairing, and you see a potential solution that your partner does not? A potential solution that your partner still cannot really see, even after you have explained it?
Potential answers include:
- (A) Guide the team towards the solution over time. This is suggested by WardCunningham on the XpIsGeniusFriendly page.
- (B) If the genius is proposing a solution that the pair cannot understand, then that solution is too complex and a simpler one should be implemented.
- (C) The genius should say TrustMe, take the keyboard and implement their suggestion.
I think all of these solutions are flawed, because:
- A genius sees things that others don't. (If the genius can't do that then they're not much of a genius, are they?) This makes (A) difficult, even if you give it time and include lots of discussion.
- The proposed solution may be, and should be, easy for the rest of the team to work with, once it's implemented. E.g. the genius solves a hard problem well, wraps the solution up in an-easy-to-reuse class, and the rest of the team re-uses it. (GeniusAsComponentBuilder?) So we're talking about a solution that will be easy to use after it's implemented. That does not mean that non-geniuses will readily understand it before it is built. So approach (B) is also difficult. Update, after some years of further experience: I would say, be very, very careful with GeniusAsComponentBuilder?. I bought into the idea, but I'm not sure I would do so again. Yes, the components were (generally) easy to re-use, but the rest of the team saw them as black boxes, never wanted to learn how to maintain them, and felt (rightly) uncomfortable with having the "black boxes" in the system. Today, faced with a similar situation, I would say, "Yes, the 'genius' solution might be the best solution to the problem in some kind of abstract sense; but it is not the best solution when the problem is to be solved by this team." That's not a criticism of the team, just a reminder to the 'genius' that the solution must be suited to its full context, which includes the people. -- from the original AnonymousDonor of this page.
- Almost by definition, a genius can hold much more in their head than the rest of us. While the average programmer finds it beneficial to work in small chunks -- test, code, test, code -- a genius can work with larger tasks and longer code-test cycles when necessary. So while the genius could take the keyboard, as in approach (C), they may need to keep it all day. What happens to their pair, sitting there all day watching the genius code something that the non-genius doesn't understand (yet)?
A key point is that others may object to the genius's proposed solution. They object on the basis that its too hard to implement. What they really mean, unconsciously, is, "It's too hard for
me to implement." Only once they actually see it up and running will their objections relax. But, in a
PairProgramming environment, the genius can't get it up and running without getting buy-in
first.
-- AnonymousDonor
If the genius is proposing a solution that the pair cannot understand, then that solution is too complex ... uh, brilliant, guys.
If the newb helped the genius notice their solution is too complex, they just did their project a major favor. Quoting Mikhail Kalashnikov, "All that is good is simple and all that is simple is good."
Never get so big for your britches that you can't learn, one way or another, from a newb! --PhlIp
Another possible solution: the pair breaks up for 1/2 a day or so, and the genius implements a SpikeSolution to show what he wants to do. He can show it in the stand-up meeting the next day, and if someone else understands it, he can pair with the genius to implement the real code. Otherwise, it really is too complex for that team to use, and you have to work out a simpler way.
More on similar lines here http://www.infoq.com/articles/adopting-pair-programming : "However, when the experience gap is too large to reasonably bridge and successfully deliver, the pair should split."
CategoryPairProgramming
Paired Genius Discussion