Pair Programming With Two Keyboards
Today when I started pair programming, me and my partner did an experiment by using two keyboards. I don’t know whether its advised to do in pair programming or not, but we started it mostly out of curiosity and fun.
Generally we pair with only one keyboard and one person becomes the navigator and the other person becomes the driver. We change the roles every half/one hour.
One major problem while pair programming with only one keyboard is that the navigator can doze off in between with his eyes on screen and mind somewhere in Hawaii. This is a pretty common thing, specially for newbies who start pairing. And if the driver is someone who loves himself and his code a lot, then he will neither know nor mind the navigator’s virtual Hawaii trip.
Other than that, the person who codes a particular part is having more control over it than the navigator. So, when we switch the roles of the navigator and driver, the new driver takes some time to have a complete control over the code. The outcomes of this can be loss of productivity due to time taken by the navigator to take the complete control over the code written earlier . And if the new driver is not able to grasp the old code soon, the new code written by him might not be the best he can write.
The navigator has to adjust himself to grab the keyboard if he wants to contribute a line or to analyze something using keyboard. The keyboard’s need arises if the navigator wants to highlight something on the code, or he wants to name/rename a variable/method/class, then writing is far better than spelling it out. Grabbing the keyboard requires a bit of shifting of chairs and sitting positions. The main point is that there is discomfort involved, which can lead to early tiredness.
So, when we started coding with two keyboards, we both had control over the code at the same time. We switched the driver/navigator role every two to five minutes. So, the code was being written by both of us. At any moment of time, both of us were having the complete picture of the code being written. No one can distinguish who wrote which part of the code. The same level of control over the code enabled us to think better than what we would have thought in a navigator’s role, which, ultimately, lead to a better design.
The other benefit was that the code was being continuously refactored by the pair. There was less talk and more coding. Whatever the problem was, no matter how small, was being fixed then and there. In short, the code was more cleaner than it would have been.
As both the driver and navigator were involved in the coding for most of the time, there was no boredom or disconnect from code involved, which prevented even a yawn, leave aside dozing off. And of course, you don’t need to shift your chair every now and then, so, its more comfortable and enjoyable.
Sometimes, we had problems when both of us started typing at the same time. To fix this problem, we kept a green flag. The person having the green flag was allowed to type, this solved the chaos pretty much.
In all, I would say that if you have not tried pair programming with two keyboards, try it out. Its more comfortable, enjoyable and productive.
Filed under: Agile, Pair Programming
Hi, It is a nice technique. As far as I remember IBM allows coding in pair through Skype in their IDE. I saw it in action couple a years ago.
Hi Paritosh,
Its good to inspect and adopt in agile. Nice experiment with pair programming. But I can not agree with using two keyboards while pair programming for the reasons mentioned. It seems the root cause is something else for the problem you mentioned : “navigator can doze off in between with his eyes on screen and mind somewhere in Hawaii”. May be you are trying pair program on something that doesn’t need pair programming. Or the navigator is not interested.
The very reason why there is one keyboard is, to have the code reviewed while it was being written. If both of them are writing the code, I am not sure the purpose of pair programming is solved here. If increasing the speed and keeping people alert is important why not use two machines instead of two keyboards.
My team of 7 has 3 teleworkers, and we’ve tried remote pair programming out – Skype for audio, and GNU screen for multiple terminal window sharing and have found this to be both enjoyable and productive.
Through GNU screen we can maintain 1 or more code windows for the actual coding, 1 for build & debug, plus any additional number for Linux manual pages or anything else. Since the multiple terminal screens are viewer-independent we can be viewing different screens, which is invaluable.
Other than that, we still maintain the usual single coder/builder/debugger aspect with the other verifying code, design, checking docs and other tasks – but switch roles on a more ad hoc basis dependent on skill, familiarity with the code and energy/enthusiasm.
Whilst not overly well-experienced in pair programming our trials of this have gone well with pairs enjoying the experience and producing more well-rounded solutions.
Certainly looks like something to be tried out. Many a times I have observed that while pair programming, the physically passive(not typing) partner feels to break for a coffee earlier than the other one, and, needs to put more effort on the task than the one who’s typing.
And, when using an IDE like eclipse, the one who’s not typing often wants to dash to an eclipse shortcut if he/she feels that the typing partner is doing something is an exaggerated way.
Having two keyboards should help in keeping the pair programming practice more lively!!
I’ve done a lot of pair programming while working at Google and Pivotal Labs. We almost always used two keyboards and two mice on one computer when pairing.
On very rare occasions, both members of a pair would try to type or move the mouse simultaneously, but you very quickly work out a rhythm and switch back and forth pretty seamlessly. I think two keyboards is definitely the way to go when pair programming.
My biggest problem with pair programming is that I too often touch the screen and smudge it when pointing to something
Hi Ganesh,
Thanks for sharing your thoughts.
However, in the post I have never mentioned that it can increase speed.
“If increasing the speed and keeping people alert is important why not use two machines instead of two keyboards.”
And anyone who has pair programmed a lot, will agree that sometimes navigators just doze off in between, no matter how complex or interesting the functionality being coded is.
And as you said “If both of them are writing the code, I am not sure the purpose of pair programming is solved here.”.
I would say that this is the very purpose of pair programming, and exactly this is why its called pair programming.
If both of them coding at the same time, then I think that is not pair programming.
“Pair programming is an agile software development technique in which two programmers work together at one work station. One types in code while the other reviews each line of code as it is typed in.” – Wikepedia
May be both coding at the same time working for your context.
If you will read the post carefully, then you will see that I have suggested changing driver/navigator role every 2/5 minutes. What exactly do you mean by coding together? No two persons can write code at the same point of time.
And regarding the pair programming definition, I will say that ofcourse, here also, “two programmers work together” “at one work station” “one types in code while the other reviews each line of code as it is typed in” AND “if any problem/idea occurs, it is corrected/implemented, then and there”. Which makes it much better.
I’ve paired this way every day for the last 5 years and feel that it is far superior to one-keyboard pair programming. In 2000 at Evant, an early XP shop, we paired with 1 keyboard because we had to! Remember that pair programming evolved before the days of USB connections so dual keyboards was not an option. At Evant we tried to set up dual keyboards and mice using available tech without much success. Once USB came along dual setups became the norm.
Other thoughts:
- as Don suggests you’ll get used to the setup soon and won’t “highjack” each other’s typing or mouse. Give it a few days.
- The purpose of pairing is not only to have a continuous code review. Having two engaged programmers is better than one. Dual setups encourage this engagement.
- @Genesh: if two programmers programming at the same is not pair programming then I don’t know what is. Wikipedia’s deff is way too narrow.
So, keep it up, stay with a dual setup for now and give a report in a few weeks!
Keep at it! I’ve been pair programming for 10 years, the last five with a dual keyboard and mouse setup. Remember that pair programming evolved before USB connections! Much of the literature is from that time. At Evant, an early XP shop, we paired with one keyboard and mouse because we had to. We experimented with dual connections using the pre-USB tech of the time without much success.
Other thoughts:
- we pair not just for continuous code review, but because two engaged programmers are better than one. Dual setups encourage this enguagement.
- you’ll stop “highjacking” each other’s actions soon enought. Give it a couple of days.
- @Genesh: if two programmers programming at the same time isn’t pair programming then I don’t know what is. The wikipedias deff is too strict.
Give an update in a few weeks!
Hi,
A colleague pointed me to this post.
I have been doing a very similar think since a long time pair-programming with my colleagues: one keeps the keyboard and the other the mouse.
I can just tell that it works really well (at least for us), in particular for debugging.
It helps focusing on the same aspects of the problem ans synchronizing thoughts. And nobody gets bored and distracted.
[...] as I can be. This includes development tools like IDE’s, good testing tools, and better pair programming techniques. But also I try to keep up with the popular Get Things Done (GTD) movement, most recently utilizing [...]
Different developers should be free to customize their own computer’s environment – text editor, macros, shortcuts, GUI styles, coloring schemes, etc. I’m not a huge fan of multiple people using the same computer, even if they alternate.
My experience of pair programming is basically there’s a driver and a visitor. For example, the driver is implementing something, and the visitor is visiting to help the developer. To answer questions, or to explain some code, or verbally guide a walk-through of an example implementation.
I like the idea of having a second mouse cursor, for the visitor to point to something (using the mouse instead of his/her finger), without actually having to go through the process of transferring the keyboard/mouse (ie, change drivers).