Pair Programming

A summary of Pair Programming video, by Neal Ford (Agile Engineering Practices)

Pair programming is a controversial agile development practice. It involves two programmers working on a pairing station. A pairing station consists of two monitors, two mice, two keyboards and a single processing unit. So, technically, it is a shared computer system. The pairing system has all the tools required for development.

The two programmers have distinct roles. One of them is the driver, who types the code and the other is the navigator, who goes through what the driver is doing. The latter analyses the code in a holistic fashion and decides whether the driver is moving in the right direction. The navigator may thus interject the driver for suggestions and/or corrections. The two switch roles frequently.

The navigator and driver may have different ideas and due to collaboration, the resulting software tends to be much more efficient. If the same project has more than one pair of programmers, pair rotation can be done, which allows all the programmers to pair with each other. Pair programming and pair rotation helps to spread knowledge within the team rapidly. If one programmer discovers something really cool, within no time, everybody else learns it.

The human brain is divided into two: the left part and the right part. When coding alone, we use only the left part, which deals with linear (step-by-step) thoughts. During pair programming, the navigator uses the right part of the brain, which deals with non-linear and holistic thoughts while the driver uses the left part of the brain. Since the programmers always switch, they effectively end up using both parts of their brains and the code thus developed is of much higher quality.

In Flow, The Psychology of Optimal Experience, the author, Mihaly Csikszentmihalyi, explains about a psychological state called flow ( that’s what the book is all about! ). When a person is in his state of flow, time completely disappears. He dedicates full attention to what he is doing and may also experience tunnel vision. In this state, people are highly productive. However, the flow state is highly fragile and once broken, it can take up to 20 minutes to get restored.

The state can be compared to sleep. We fall asleep unconsciously. But when somebody wakes us up, it will take time to get back to sleep again. Similarly, the train of thought, once broken, will take time to get loaded back into the brain again.

During pair programming, it is possible for two people to be in the flow state at the same time! That is a really powerful source of productivity. Moreover, when we work in pairs, people are less likely to interrupt us presuming we are busy, as opposed to when we work alone. This helps retain the flow state for a longer period of time. A person also ends up wasting less time after breaks since he knows that the other programmer in the pair is waiting.

Pairing is tightly feedback-driven. Coding is the most complicated part in the development cycle and getting correct feedback at the right time helps increase productivity and decrease error rate.

The driver narrates his actions, which helps him understand better what he is doing. It is proven that when we recite something, we’ll be able to comprehend it in a much better manner. Pairing helps in knowledge-sharing and communication. It also makes programmers experts at explaining complex technical concepts.

Furthermore, it is fun too..!!

What pair programming is not

1. Two people crowded over one computer
2. Mentoring - Mentoring is when one person is learning and the other is coaching. This is a little hard for both parties, because the coach has to slow down for the learner to understand and the learner needs to push himself beyond his comfort zone to understand things better.
3. Keyboard domination - This happens when one person loves to type. One idea to avoid this situation is to combine it with Test Driven Development. One person writes a failing test and the other writes code to make the test pass then writes another failing test. The former now writes code for that second test to pass, and this process continues.
4. Pair marriages - This happens when pair switching does not happen.
5. Less productivity - The decrease in productivity is not significant when compared with the decrease in error rate. In fact, errors take more time to get fixed during later stages.

Isn’t it awkward if I pair with someone who is much better than me? Of course not!

- “When you play with a better player, your game gets better.”

Thanks to +Jerry John Jacob for the proofreading and edits.. :-)