[A more handy term is perhaps HueyPairProgramming.]

I found this on CorwinLightWilliams WikiHomePage, but it's a valid discussion about PairProgramming.

I've found that there is a useful variation to classical PairProgramming that involves streamlining the verbal exchange.  I once tried this with a pair that I knew well.  We also had the facility of a workstation with USB and two USB keyboards and two USB mice plugged in concurrently.  This allowed either keyboard/mouse pair to instantly and unproblematically take the DriverRole.

I had remembered a book I read called Chickenhawk that described helicopter pilots in Vietnam in detail.  Each helicopter was required to have two pilots (see the connection?).  They had a mandated communication protocol that reduced the latency of pilot control switching.  It went like this:

Assume P-A is Programmer/Pilot A and is in control, and P-B is Programmer/Pilot B.
When:
	* P-A wants to give control to P-B:
		* P-A says "You got it." (maintains control.)
		* P-B assumes control
		* P-B says "I got it."
		* P-A releases control.
	* P-B wants control:
		* P-B says "I got it."
		* P-B assumes control.
		* P-A says "You got it."
		* P-A releases control.

(In the programming case, "assumes control" would usually mean "puts hands on mouse and keyboard.")

This is basically a low-latency, low-overhead context switch.  With the dual input, it allows a minimum of conversation (only two distinct phrases) while allowing complete control to transfer without missing a beat or (hopefully) disrupting the MentalStateCalledFlow.

As written, it might look complex.  I assure that once it is tried, it is thoughtless (in a good way) and yet meaningful.

This method solves a number of the more subtle issues that arise even after a pair is convinced and experienced with PairProgramming and it's ideas.  These subtleties include:
	1. You are driving, but you know the other person has a better understanding of the immediate problem.
	1. You are really in a flow, coding fast (and perhaps losing larger focus) 
	1. The other person has an idea that is hard to describe in words, but only wants to interject momentarily.

These are all problems with '''communication''' at the core.  In (1), it is often faster to just switch drivers than to explain that you think the other may be more useful at the moment (a fact which the other may well know already!)  For (2), the other may not want to stop your flow to try and explain some important (usually more abstract!) concept.  For (3) and for all of the above, the idea of physically switching chairs and ''getting up'' might seem to much of an impedance for a pair (we're nerds right?) to bother.

This idea stemmed from a trend I noticed after a few years of XP and pairing: Switching the DriverRole is often too big of a task for efficient developers.  What tends to happen is putting off switching until something happens: an exercise/wrist break, a major code delineation, a task switch, etc.  This is often counter to the flow of the pair.  By reducing this overhead, switching can happen in a more fluent manner.

The protocol simply defines a lightweight way to do this, that is mutually agreed upon so as to allow verbal communication to focus on more important tasks, such as the code itself, rather then "Um, ok, can I just take the keyboard here for a second? Thanks."

Comments Please?

  -- KarlinFox
----
03-19-2014 - I like it. I'll have to try that. I know how it works when flying. I can imagine it could improve productivity with the right programmers. But it would require the right programmers.
----
"Instructor's airplane."

"Student's airplane."

"Instructor's airplane."

All three phrases are uttered by the instructor in this case.
----
Requiring victory in a PhysicalContest such as BodyweightExercises in order to take control would increase health among programmers.

''It should be a fight to the death.''
----
See: PairProgrammingVariationsAndAlternatives, VirtualPairProgramming