Pair Programming

Pair Programming (PP) is maybe the most well-known coding practice that emerged between 1996 [Wells 2013] and 1999 from Kent Beck’s Extreme Programming (XP) agile framework [Beck 2004] although such practice was already reported back in 1995 [Nosek 1998] and also as an organisational pattern [Coplien 1995].

It consists of having two people working on the same workstation. They [Beck 2004]:

“Keep each other on task”

“Brainstorm refinements to the system”

“Clarify ideas”

“Take initiative when their partner is stuck, thus lowering frustration”

“Hold each other accountable to the team’s practices”.

Usually with two roles emerge [Kniberg 2015]:

the pilot/driver: this is the one who holds the key board

the co-pilot/navigator: this is the one who assists the pilot, reviews the code, tries to challenge what is done so that the generated artifact is at its best and think strategically about the implications about the design [Williams 2000]

Roles are swapped on a regular basis to gain collective ownership [Kniberg 2015]. Immature PP goes like “ I have an idea, give me the keyboard ”; while mature PP is rather “ I have an idea, take the keyboard ”. There are several recommendations linked to PP [Llewellyn 2014], but the most important one is strong egos with a “ my way or no way ” mindset that should be avoided [Williams 2000].

PP works best if people know each other and it is highly recommended to split pairs that don’t fit [Naresh 2018]. PP with two beginners should also be avoided [McConnell 2004].

There are numerous advantages to work in PP [Williams 2000] [Vanhanen 2007]:

it reduces the probability to produce bad design [Flor 1991]

it removes flaws on the fly as proposed in the Kaizen approach

it is also good for knowledge sharing and training in hands on mode

it helps people to face challenging tasks

it improves job satisfaction and overall confidence in their work

Regarding productivity, it appears that pairs spent 10-60% more time on tasks than separately while they completed the task 40-45% faster than the control groups, and produced better algorithms and code [Nosek 1998][Shull 2002].

Fixing issues on-the-fly is also beneficial for the First Pass Yield and is much more profitable since fixing issues afterwards would raise fixing costs to 15-60% [Williams 2000].

Other studies reveal that [McConnell 2004][Moustier 2019-1]:

1 hour of PP avoids 33-100 hours in maintenance and reworks

40% less in rework for 20% dedicated to PP

Hewlett-Packard would have save M$21.5 with PP

Therefore, programmer-hours do not double with pair programming and it delivers faster with higher quality [Williams 2000].

Testers should PP with Developers that are writing test code. Even if the Tester can’t code, the Developer will keep the keyboard and tell about the test being coded to let the Tester improve the underlying testing ideas [Kniberg 2015].

When it comes to TDD , it appears that Pair Programming strongly supports TDD since

the code review on-the-fly ensures the tests are of high quality [Parsons 2011]

since TDD is a matter of design, PP reinforces solid design

TDD can also be used to transform PP into “Ping-pong programming” [Hoover 2005]:

1. Dev A writes a Unit Test (UT) that must fail (“Red”) and hand the keyboard to Dev B

2. Dev B tries to make the UT “Green” and eventually refactors the code

3. Dev B adds a new UT that should be “Red” and hands back the keyboard to Dev A

Pair Programming can be used on any kind of activity, testing included. For instance, the “ 3 Amigos ” workshop is actually a PP session with a Dev and a Tester around a User Story - the PO acts then like a compiler or Test Oracle who provides answers on Dev/Tester’s inquiries. Doing Pair-Testing will result in [McConnell 2004] [Vanhanen 2007] [Moustier 2019-1]:

lower fallacies

higher concentration

testing in PP mode is 20 times more efficient than traditional functional testing

PP would divide the number of bugs left in the code by 5

Applying PP in scripting with Agilitest seems obvious, at least on scripts to automate that are supposed to last. Taking benefits of known PP advantages is something really interesting to try, especially when the Tester pairs with the Developer of the US. This leads to improvements in both scripts and production code notably in terms of

testing scenario - completion regarding what both Dev & Tester understood about the US, the implemented feature should converge more surely to what actually is expected

widget retrieving method - the Dev may adapt the widget creation to speed up and consolidate widget recognition

since PP enables learning, it leads towards T-Shape people and enables test automation as well

any other testability needs may be rapidly taken into account by the Dev to facilitate Jidoka

from this collaboration, script automation can be done in just-in-time mode and eventually lead to synchronized development & test automation ecocycles .

‍

To discover the whole set of practices, click here .