As explained in my last post, I chose to attend the academic track, with the practitioners track being filmed, to be watched later.
The academic track involved presentations of numerous studies related to the application of Agile methodologies in the work place, generally trying to evaluate whether Agile principles have a quantitative impact on the development process.
Participation Balance in Pair Programming
‘Participation Balance in Pair Programming’, was the first session, presented by Laura Plonka, who I had previously met at last years XP Day 2010, and had joined in a discussion of our pairing practises at Codeweavers.
Pair programming during development tasks typically involves one developer controlling the mouse and keyboard, while the other developer keeps an overall idea of the task at hand, advising on the course of action the pair takes. This pairing is usually equated to Rally driving, where the person at the keyboard is the driver, concerned primarily with producing valid code, while the ‘Navigator’ keeps the map in mind, and advises the driver of directions for the road ahead.
The big difference is that during pair programming, it is very easy and often useful for the roles to be swapped mid flow, something I’ve never seen in a rally.
This is the premised on which this research was based; that is it preferable for developers to have an equal contribution in a programming session terms of both time driving and verbal contributions throughout the session.
The results quickly indicated that pair programming sessions were very rarely even close to equal, both in terms of time driving and verbal contributions, which I would say is fairly representative of pairing at Codeweavers.
Reasons for uneven contributions
The study then looked at reasons why the pairing contributions may be uneven, and found several factors such as:
Workstation ownership; A person working at their ‘own’ desk, may have a preference for driving because they are more familiar with the desk, and the machine has been personalised to their preference, including specific software and even development environments in some cases. In our case, we try to keep a standard development environment, so developers have no preference of workstation.
Difference in Skill/Confidence;
Typing speed, confidence and experience may lead to a preference for a particular role, with motivated, experienced developers preferring to drive, while inexperienced developers with low self-confidence may prefer the navigator role as it is stressful to write code with someone watching. Inexperienced developers may also be aware they are slowing the session down, and so prefer to let their experienced partner drive.
Personal Preference and Work Style;
Developers may have different approaches to development which can cause a preference in roles, where one developer may employ trial-and-error, another may perceive this as frustrating, preferring to read through and understand code first. These frustrations increase the likely hood of one developer ‘tuning out’ during the session
The next question the study attempted to answer, is what these finding meant, what are the implications of imbalanced pairing?
The researchers also asked the developers on their opinion of how well the session went, and found no correlation between perceived successful sessions and equality of contribution, which is something I would agree with from personal experience.
While I am aware that most sessions are not balanced, some of these uneven sessions have involved driving while an experienced driver watches over, with only occasional contributions, in fact sometimes the lack of interruption from an experienced navigator can be a big confidence boost, while still providing the safety net of experienced eyes covering the code I’ve produced.
So should we strive for equal contributions in pairing?
I think having seen the results of this study, and my own personal experience, I would say that while equality isn’t essential, it is certainly preferable, as the pitfalls of pair programming such as navigators ‘tuning out’ and loosing attention, or drivers following instructions without thinking what they are doing, are both problems addressed by alternating the roles throughout the session, in fact one of the techniques we employ at codeweavers is ‘ping-pong’ pairing, where developer 1 writes a red test, then hands over control to developer 2, who implements code to fix the test, then writes the next red test, and returns control to developer 1.
And when new developers arrive, we employ the ‘inexperienced developer drives’ idea, to engage new developers immediately, and hopefully encourage contributions and social interaction early on, so while I feel equal contribution during a session should be the goal, it isn’t the goal of pairing, so sessions should be judged on the benefits we look for in pairing, i.e. knowledge sharing, increased code quality and better development experience, rather than how even the contributions were.
Integrating Agile Development and User Experience Design: An Achievement In Practice