As we prepare to teach the first year of the GSA pathway, we’ve been experimenting with techniques more commonly used in software development to see if they can help us to deliver quality and integration in our new modules right from the start. This post will explore the logic of Pair Programming.
What is Pair Programming?
In the traditional software development arena applications are designed by a group of experts; they then hand a set of requirements over to a programmer who heads off to their desk to write the code that will meet those requirements. If the requirements are sufficiently well thought-out and extensive then delivering code that meets those requirements means the project is a success.
There’s just one problem: how often has anything complex been sufficiently well thought-out that individuals, working in isolation, have been able to deliver something integrated and feature-complete on the first go? Actually, there’s a second problem: it is also possible to write something that fully meets the requirements, but doesn’t meet the needs of the application or the organisation. While I work away on ‘my’ bit, I miss a major issue that was also hidden from the application’s designers because no one has an eye any longer on the ‘big picture’ of what the application is supposed to actually do.
It’s into this breach that Agile-derived pair programming steps as a way both to keep developers looking at the big picture, and to enable individuals to access the type of practical knowledge that is only formed through long or diverse experience. Sometimes called peer programming (which is a rather nice terminological link to academia), pair programming matches a ‘driver’ who focuses on the tactical aspects of task completion with an ‘observer’ or ‘navigator’ who “continuously and actively observes the driver’s work, watching for defects, thinking of alternatives, looking up resources, and considering strategic implications” (Williams et al., 2000). In other words, the driver has someone looking over their shoulder… but in a constructive way.
Issues in Pair Programming
Can it work? Programmers aren’t known for their tolerance of being supervised or managed during programming tasks, so there are a number of techniques designed to make this a more constructive experience: for instance, the pair switch roles regularly so that each person ‘drives’ for a while and then puts on the strategic thinking hat for a bit. And repeat. The constant role-switching means that both programmers have an opportunity to do both types of thinking, which builds up practical knowledge and also helps to ensure that many more possible approaches to a problem are considered.
So, by pairing old hands with novices pair programming encourages sharing of ‘best practice’ and yields immediate and frequent feedback during development. That said, you don’t ordinarily pair very experienced programmers with complete novices because the knowledge gap is too wide; it’s common to pair novices and intermediates, or intermediates and experts, with the idea being that the more experienced person still remembers having to learn what their ‘junior’ is trying to understand at the same time as it gives them a chance to systematise their own experience through teaching.
Obviously, some level of social aptitude/sensitivity and trust is also going to be important here, but somehow many Agile firms have managed to make it work. Interestingly, developers actually report finding the process quite enjoyable, while businesses report 40% faster turnaround, more efficient code, and fewer defects (ibid.). And it has been noted that pair programming works best on challenging tasks that call for creativity and ‘sophistication’ (Lui and Chan, 2006).
Applications in Academia
These types of benefits are clearly relevant for thinking about teaching and administration in academia where there is often a poor understanding, especially amongst new hires, of the objectives of a particular task, its rationale, and the range of viable solutions. So while none of us involved in the GSA pathway would claim to be experts in either module design or programming, we thought that pairing would be useful for new module development because we could cover each others’ ‘weaknesses’ while also talking out the overall strategy of the modules themselves.
So far, the results are really promising: although two of us had to invest fully 1.5 days working together (and switching offices since no one else can use my Kinesis Contour keyboard) to develop a week-by-week teaching plan that incorporated pre-class readings, in-class concepts, and practical work, I feel that the result is looking much better – more integrated and with an obvious appreciation of what concepts need to be covered in which weeks in order to bring the students to the final assessment – than if we’d tried to each tackle ‘our’ bit independently. We also brought more ideas and resources to bear on how we might teach each concept and came up with what I think are really good ideas for testing student learning.
Personally, I’ve found it so productive that, where remotely practical, I’m thinking of inflicting it on every team taught module I’m involved in. That said, like all things it’s probably best in moderation and may be most valuable during the planning stage, less so during the “I need to create my PowerPoint slides” stage.
So that’s peer programming – or, in this case, peer planning – and we’ll try too post about the other techniques and tools we’ve experimented with over the coming months.
References
- Lui, K.M. and Chan, K.C.C. (2006), ‘Pair Programming productivity: Novice–novice vs. expert–expert’, International Journal of Human-Computer Studies, 64(9):915–925.
- Williams, L. and Kessler, R.R. and Cunningham, W. and Jeffries, R. (2000), ‘Strengthening the Case for Pair Programming’, IEEE Software, July/August 2000, pp.19–25.
