Add Pair Programming to Techniques as Adopt

[pburls]

Pair Programming is an Agile software development technique in which two programmers work together at some kind of shared workstation setup. One, the driver, writes code while the other, the observer or navigator, reviews each line of code as it is typed in. The two programmers switch roles frequently. We believe that although this may seem as an inefficient usage of our developers' time, the quality of the code produced leads to less time consuming problems later. Other benefits include improved knowledge and skills sharing and team communication.

[guymsi19]

The interesting issue with Pair Programming is that it is easy to do completely the wrong way. With most other things on our tech radar like Kafka, Spring Boot, and Docker, you have to do them at least mostly correctly otherwise it simply doesn't work. If you introduce a breaking change for example, you will know because the application will stop working.

My observation is that there has been little to no training on Pair Programming and there is the incorrect perception that it simply means a problem is solved by sitting two people in front of one computer. While attempting to pair program on my current team we initially did not know how to do it properly and suffered considerably because of it.

So my point is, Pair Programming can be a good thing, but when not done correctly it can also be a bad thing. Adding it to the tech radar should be done with caution and if possible should be accompanied by some sort of formal training for everyone involved. At absolute minimum the tech radar should clarify that Pair Programming should be used only on those tasks where it is deemed appropriate.

[emarques]

In my team we always work as a dev-pair.

It promotes knowledge sharing and also getting newcomers up-to-date with and how the team works. I think it is an absolute must when starting a new project with new team, so everyone can get into the same mindset. Once everyone works almost in the same way we tend more to separate tasks.

Another advantage that I see with using Pair Programming, is when tackling problems, one might get too focused on one solution while programming, and it's common for the other person of the dev pair give other suggestions to tackle that same problem in a better way.

[guymsi19]

I hope I haven't given the impression that I don't think we should be pair programming. I just think we need to be taught what correct pair programming looks like so we can know what we should be striving for, as well as be able to recognise when we aren't doing it properly, what the reasons are, and what needs be done to address it.

[pburls]

@guymsi19 I agree we should include in the blurb some points on what good look likes and what bad looks like. Can you suggest any?

Also we should describe some links to some supporting material.

We can also look for someone who might be interested in talking about this to the community. Know anyone?

[emarques]

@guymsi19 I understand that, I know that in some teams, due to the way they have been working it's harder to do that. Totally agree that we should be thought on how to pair programme, or to do it in a way adjusted to each specific team, that works the best for them.

[cameronramsay]

I'm an advocate for pair programming, but I think it's also important to get the balance right. On a previous team, the developers paired pretty much every hour of the day. The majority of the team loved it, and felt that it was the right approach. But it turned out that a couple of guys felt that they were unable to 'think' for themselves, or unable to learn by making their own mistakes. I think it's also important to rotate pairs. On that team, we rotated pairs every other day, which often meant that every developer in the team had worked on a story. Great for knowledge sharing, but the time to deliver also increased.

[bjcoombs]

Hi, in team @sky-uk/pmp we pair programme.

It works. However, it works because we have a number of other team norms we now take for granted that form the foundation of why it works. Off the top of my head heres some of the other team norms we do that make it work:

• 5 Pairing stations, each with exactly the same setup, cloned from a mac time machine backup base image, we don't own desks, we can work as a pair on any station. Each station has a pair of keyboards and mice, the station is owned by the card in play.
• We have time outs, we have a bell we can ring to discuss problems and solutions together collectively, during this time, one person speaks, everyone else listens.
• We have daily stand ups, with an agenda, time boxed to 15 minutes where each story is given an update.
• We have story etiquette where we document who ever has worked on it.
• We have a pairing station GitHub user that pushes commits, we use initials of team pair to document in the commit message who has worked on the commit.
• TDD is not optional.
• We have preplanning sessions, planning sessions, showcases and retros, this operates at a weekly cadence.
• Everyone's opinion is valued.
• We all own the codebase, we are not precious about individually owning parts of the system.
• Everyone wants to pair, pairing is the norm.

I've probably got more points, but this is a good starter and why it works in pmp.

[emarques]

Rotating is another good subject when it comes to this. In my team, what seems to work is 2 weeks with the same pair (this matches our sprints), in the beginning we were rotating every week, but that seemed to have an negative effect in the amount of context switching that one had to do every week.

[pburls]

@bjcoombs Thanks for the insight. Do you have any examples of what your teams struggled with while pairing in the past?

[pburls]

@emarques @guymsi19 @cameronramsay @bjcoombs I've created a Pair Programming "Way of Working" document to capture this topic in more detail. Please feel free to comment more on it here: https://github.com/sky-uk/csp/pull/2