Six Degrees Of Pair Programming

18 Oct 2016

6DOfPP

Here are 6 different examples of real world pairing positions that function as a unit :-

Pilot and Co-Pilot - a monitoring backup pilot can assume command

Motorbike and Sidecar - attached outside passenger along for the ride

Learner Driver and Instructor - Teacher with dual controls that can override

Pantomime Horse - positioned one behind the other, one person acts as the horse’s front half, the other forms the hind part

Bert & Ernie - A pair of inseparable Muppets

Eric B. & Rakim - DJ and MC but only one is the G.O.A.T

The Cargo Cult of Enterprise Agile

The ritual of Pair Programming is still represented with the quaint assumption of coders being able to work next to each other all day and where the ergonomics of working together side by side in Open Plan spaces are not being considered.

Collaboration in Software Development is quite noisy and there must be a consideration of placement in a private room where two or more developers can work with less inhibition - There is no point in adopting paired positions when the working environment is not adjusted and fitted for that purpose.

One of the principles from the Agile Manifesto :-

Build projects around motivated individuals. 
Give them the environment and support they need,
and trust them to get the job done.
- http://agilemanifesto.org/principles.html

You may have encountered Agile Consultants, on billable engagement, intoning that Pair Programming is the “most important” aspect of the development cycle.

The working environment is the most important aspect and sets up opportunities for Pair Programming be it co-located or remotely.

If it’s that important then what does a Pair Programming working environment actually look like and why don’t they advocate for that as a prerequisite?

Space Invaders - In reality, it looks like two developers working at a standard sized desk - awkwardly squeezed armrest to armrest, flailing at the shared keyboard and mouse controls; this repeated across the working space with other developers nearby.

This open space is supposed to evoke a War-Room with developers communicating “intensely” - noted from The Practices of Extreme Programming - Agile Software Development (Robert C Martin)

Peer Programming not Pair Programming

We can still have the goal that nothing can compensate for knowing what you are producing is being reviewed and collaborated on in real time. The key is to learn what to code as well as when and why.

Two wrongs don’t make a right where a Pair can still come up with a defective solution.

Some kind of Peer Programming intervention enables the quickest way to stop defective code from making it into production.

Code reviews by nature happen too late in the process; often cited as the reason for Pairing to start with.

Every organization is a distributed system, by identifing the earliest possible moment at which to design code, we can find and highlight examples of good code even if we are not actively working within the same module.

Peer Programming is familiar to online gaming where it’s immediate, with headsets on, to get in the zone.

Make the primary means of achieving code quality be knowledge sharing across the code base and across the team.

Giving developers the right environment will allow them the latitude to figure it out for themselves - be it Pair Programming or Quad Programming.

Environment Drives Culture - Culture Drives Brand