Monday, August 1, 2016

Driver is not a typist

I listened to a talk today on How Agile and OO have lost their way by James Coplien. At around 48 minutes into the video, James introduces Mob Programming.

"One of the very exciting things I've seen emerge recently is Mob Programming ... Kind of like pair programming, except it's the entire team. You have one person at the keyboard, they may not think, they may not talk. They only type. You have a facilitator, and the rest of the team writes the code and tells the typist what to write. Then you swap roles every few minutes."

We (myself & Llewellyn Falco) teach strong-style pair programming, especially in mob programming with the phrase "no thinking on the keyboard" that I've considered dangerous. I've recently observed many misunderstandings from this, and softened the expression to "no decisions on the keyboard". Thinking is allowed, encouraged even. Talking back to the navigators is allowed, encouraged even.

Seeing how James frames Mob Programming driver role as "they may not think, they may not talk", I feel the need to thinking about how to communicate this better.

Woody Zuill talks about a dumb input device (the keyboard) and the smart input device (the driver). The smart input device is not a typist, but a translation. The person on the keyboard primarily translates intent like "we'll need an invoice class" or "there should be a method for creating new employees" into implementation. The driver is navigated on the highest abstraction level possible, and has a lot of power in the order and details of implementation. If the navigators disagree on the choices, a discussion emerges through the continuous review. And if the driver is a beginner as programmer, the navigators drill down in the navigation instructions to the level the driver needs.

Within just a few hours, you see a newbie move from "type var" into "we'll need a variable to store the employee info" in the instructions. Details and typist-level instructions are momentary, and the option we revert to when the driver needs it and we move beyond typing quickly.


  1. Maaret, Woody Zuill, in characterising the role of the Driver, says that in mob programming, it is (direct quote) "Out of somebody's brain, through their mouth, into someone else's ears, into the computer." In the archetypical description of the configuration, the Driver is smart, but passive. Woody also suggests that the Drivers remove themselves explicitly from the design dialectic in pointing out that they should switch out of the Driver role to contribute. Direct quote: "If the Driver feels they have something to contribute, they also can be a Navigator for that moment." Thinking Drivers may neglect to telegraph what they type to the rest of the group, so the context switch brings the Driver out of the role as an extension of the keyboard and into the role as an active participant in the dialectic.

    Sure, the neurons of the Driver are working at least to the point of driving the semi-unconscious process of translating the navigator's conclusions into syntactically correct code. As psychologist Satir noted, you can't not think. But to focus on this detail distracts from the more strategic thinking about the problem to be solved and how to solve it. And, as described above, it can contribute to unshared modifications to the code.

    Woody describes the Driver as "a smart input device." Keyboards don't think. He says "They know how to take things in at different levels. A beginner needs, maybe, control-T, then use the Intellisense and get the rest of it ... — we tell them line by line." Direct quote. If that's what "thinking" means on your team, I think you can aim higher. Even with advanced people it's only at the level of "I'm going to need some kind of collection object, and it's going to have a collection of customers, or whatever... So I can talk at a higher level." (Another direct quote. And he takes it no further than that.) This compresses the communication channel but it still seems to be that this is largely a translation job rather than a major cognitive contribution.

    I have found that using the Driver as a "smart input device" rather than a key player in the collective thought process who deals with the distraction of typing on the side helps keep the Driver from having to make cognitive context shifts from the detailed analytical work of coding to the broader analytical work of design. There is no recipe for Mob Programming, and I fear you are trying to formalise an experience that is, well, experiential. It is also clear that you and I have a different vision of what Mob Programming is, and I've done my best here to relate how we have been doing it since the 1980s in AT&T and as Woody Zuill describes his experience. You are welcome to share your experience. You are unwelcome to invalidate mine.

    It is amazing that someone who claims to be driven by context took no more than 20 seconds of one example out of a 50 minute talk and found something to pick on for their own exposure and publicity on the web, without extending the courtesy of checking with me first. I think my audience understood me (based on follow-up conversations) and, if they didn't, they could (and did) ask. Mob programming is based on kindness, respect, and consideration. I wish you had respected me enough to contact me in person (we know you know how) before publishing what I consider to be misinformation and which is in any case contentious. And I wish you wouldn't represent as authoritative truth what Woody himself says everyone should interpret for their own sake. It reflects well on you only to those who are looking to be told what to do, and who choose not to think for themselves.

    1. James, Woody quotes Llewellyn Falco on stroing-style pair programming as the mechanism driver/navigator work:

      It's an idea, not instructions that must go through someone else's hands.

      You're free to have a discussion about the intent and message with Woody and Llewellyn - I have. Last time on Saturday, when I participated one of Woody's trainings.

      I'm trying to describe what I'm learning and realizing from various inputs. Your description in the talk triggered a detailed discussions I've been having for a longer time. I'm not trying to invalidate your experience by detailing my insights.

      I believe I can write about my thoughts, just as much as you can talk about your thoughts. Sometimes comparing the thoughts results in more insights. Insulting me continuously on various channels and actively trying to see me doing bad things isn't really a fruitful place for a discussion.

      My blog post isn't about your talk in total, just the trigger that I picked up from it on the idea of strongly saying that thinking, even speaking is not allowed.

      My blog isn't an authoritative truth, it is my view on things. I try my best to understand and write on things that I find meaningful to me.