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
- Two people crowded over one computer
- 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.
- 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.
- Pair marriages - This happens when pair switching does not happen.
- 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.”