All About Pair Programming!!
It’s about a conversation between a fresher(Jerry ) and an experienced employee(Tom ) both working as a developer in an IT firm.
Jerry: Hey Tom, I am new to this agile world and from the time I joined, I am noticing that people here follow agile very seriously. I am trying to learn agile practices, can you help me in understanding some of them like pair programming, what is it? Is it really helpful? And what are its benefits and are there any anti-patterns of it?
Tom: Hello Jerry, welcome to the Agile world!! Sure I will help you in understanding “pair programming” 😊 😊
Tom: As per definition, Pair programming is an agile software development technique in which two programmers work together at one workstation. 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.
Tom: Let me make it simple for you. Pair programming is followed in agile methodology in which 2 programmers work together by sharing the responsibilities.
Jerry: What is this driver & navigator? I mean why do we need 2 programmers to write the same code ❗Will this not result in more developer involvement instead, one developer can complete the code and the other can simultaneously work on another piece of code? 😕
Tom: No, Jerry, the main concept of pair programming is that only 2 programmers will be dedicated completely for one piece of code. A driver will be dedicated for writing code with the aim in mind to complete the current task while the observer/navigator observes the bigger picture of code & focuses on each line that the driver is writing & suggests improvement of code whenever needed.
Tom: I agree with you that this will result in more developer involvement but this also results in more efficient code as one developer will be completely dedicated to observing the quality of code and suggest improvements. This way there are few chances of errors & ultimately what is required is good quality code.
Jerry: Ok got it!!! But is it like the driver will always hold the keyboard for writing code and navigator will always navigate? When do they interchange their role?
Tom: Yes, there is a concept called ping-pong programming. In this, the driver writes the test for some unimplemented behavior and fails the test by running it. Then the navigator writes the implementation of that behavior and makes the test pass, thus switching between their roles. Ping pong programming is a combination of pair programming and test-driven development.
Jerry: Oh, nice!! This sounds quite cool but is there any problem associated with pair programming?
Tom: Yes, it is quite commonly observed that while playing the driver-navigator role, navigator might get distracted easily which will affects the quality of code and indirectly the driver’s performance.
Jerry: Yes, but you just told about ping pong programming that might be helpful for solving this problem isn’t it?
Tom: Yes, now you are getting the concept of pair programming 😊
Jerry: Yes!! but I want to know if there are any other benefits apart from effective code?
Tom: Yes, there are many other benefits of pair programming. When you are pairing, there is a lot of knowledge sharing between driver & navigator. In my past projects, I noticed that pairing helped in faster onboarding, as the context sharing becomes a lot easier when we code in pair.
Jerry: Yeah !! Agree with you.
Jerry: So Tom, I understood that pair programming is quite effective but are there any bad practices related to it which I can avoid?
Tom: Bad practices means are you talking about anti-patterns of pair programming?
Jerry: Yeah!! Anti-patterns of Pair Programming.
Tom: Well, there are a lot of anti-patterns of pair programming. Let me explain to you some of them in brief so that you will get an idea of it:
Pair affinity: If Mr. X wants to pair with Mr. Y every time and is not ready to do pair rotation, it leads to Pair Affinity. This is harmful to the team’s agility and defeats the purpose of pair programming. ⚔️
Keyboard hogging: When Mr. X is not giving the keyboard to Mr. Y and thus not allowing him to write code that leads to Keyboard hogging. There are developers which develop this habit of grabbing the keyboard for longer times, which might result in other developer feeling lost and thus provides no contribution to the codebase.
Pair absenteeism: I observed this anti-pattern quite commonly in projects. There might be situations that your pair is not present with you for pairing; then you will get stuck if you wait for your pair(which might not be the case every time) and even if you start coding without waiting, then also once your pair is back, you need to spend extra time in explaining the code that you wrote alone which leads to an extra effort.
Passive programming: Passive pairing is something when only one developer is providing inputs/ideas for proceeding further in user stories and the other one is just sitting idle and agreeing to whatever the other pair’s idea is, without thinking the consequences of that idea. I also observed that sometimes because of the aggressive nature of a pair the other pair turns out to be passive. So we need to be quite careful while pairing with other developers.
Jerry: Ohh! this seems out to be quite useful information. I will try my best to avoid these anti-patterns while doing pair programming 😊.
Jerry: Tom, I have one question in my mind. Sometimes there is a very small piece of work that we need to complete as a part of a story and for such a small piece of work, I doubt if pairing will be helpful?
Tom: Correct!! You need to pair or not is decided according to the task that the pair needs to complete. If the task is too small and pairing is not required you can do Pragmatic pairing. Pragmatic Pairing is done when the work is too small. In Pragmatic pairing, you discuss the ideas, concerns with your pair, and then you both do solo work simultaneously. If you are stuck somewhere, you again take help/discuss with your pair and continue working separately.
Jerry: Ahh!! Nice I got to know a lot of new facts about pair programming.
Tom: Jerry, I am happy that you understood the concept of pair programming but just remember these facts while you do pairing:
- Always discuss the ideas/approaches with your pair before starting to work on user stories.
- Use a monitor and both developers should focus on the same monitor.
- Encourage open communication.
- Ask questions if you don’t understand.
- Ask for help whenever you need.
- Take short breaks whenever you or your pair needs.
- Switch roles after some time.
- Do regular pair rotation.
- Take ownership of code and give the same chance to your pair as well.
Jerry: Thanks a lot Tom for sharing the concepts of pair programming. I will try to follow this in my future projects.
This is all I want to share about pair programming. Please feel free to comment if you want to add something to this post. 😊 😊
