Why Pair

On teams, developers want to get more done. Less experienced developers need to learn from the more experienced developers. The organization needs to be structured to avoid needing n squared communication channels.

"Pair programmers: 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. Pairing" - Kent Beck

Pairing allows developers to ...

• Produce better solutions
• Share knowledge and context on the fly
• Mutual learning and skill development

Definitions

Pair programming is the practice of pairing up to work on development tasks. Most people think of two developers sitting at the same machine, sharing a keyboard. With the increasing popularity of remote work, it is now possible to pair program while thousands of miles apart.

Driver

Fingers on keys; typing code.

Navigator

The developer that indicates what should be typed; decides the direction to go.

Most forms of pairing involve taking turns typing. One person types (the driver) while the other person thinks through what is being done, and what needs to be done next (the navigator). These roles are frequently swapped.

Both members must verbalize their thought processes when pairing to be effective. Successful pair programming relies on successful communication as much as programming skills. The premise of pair programming is that when working on a complex task, "two heads are better than one."

Patterns

Strong Technique

The Strong Technique is an approach where the driver does nothing that the navigator did not direct.

For the driver to provide an idea, they must handover the system to the partner and then carry out the control from the navigator position. This approach completely engages the observer.

Traditional Technique

Traditionally, pair programming has been popularized through the driver-navigator technique. Ideally both the team members should switch roles at times for better results.

With this style of pair programming, the navigator often loses interest. Possibly because the person in charge of typing is not communicating well, or perhaps the navigator does not want to bother him. Many times the driver puts forth, "just a minute, I’ve got an idea ..." and continues working; the navigator is left behind.

Ping Pong (TDD Swapping) Technique

Using this pattern, one of the developers writes the test that fails and the other developer writes the code to get the test to pass. Then, the pattern is repeated.

The biggest challenge with this pattern is finding time refactor the code and do testing. In fact, more time is often spend on the test refactoring than the coding. Implementing a feature can be complicated and it will make testing complex too. Developers must also pay attention to the simplicity of the code so that it can be effortlessly maintained in the long run. This idea also applies to testing.

Leap-Frog Technique

This pattern can be best described by looking at two developers in different time-zones. One is working on front-end code, the other on back-end code. They work toward a common feature, taking the development lead ... moving the code forward.

Rubber Duck Technique (Grab a Buddy)

Here, the pairing is often two developers at similar levels. One, working on some code, is stuck and in need of an "extra pair of eyes." Often, someone not as "deep in the weeds" will be able to see what the original developer missed.

Mob Technique

The Mob Technique can be used well with code abstractions to develop a conceptual implementation.

This technique allows several developers to contribute at one time. Many are referencing code and finding implementation patterns for use or validation, while one or two individuals are writing code.

This technique could also be used when in a teaching (or mentoring) role to give the group room to explore and examine code patterns.

Conclusions

Pair programming, when done correctly is a powerful tool, but it can easily go wrong and ...

• Should never be forced.
• Should not expect different results or speed than traditional development.
• Is not about "showing off."

Images

Icons made by Freepik from Flaticon is licensed by CC 3.0 BY

Leading EDJE