How to make Code Review more effective with Pair Programming
The “Nazis” in Code Reviews
Did you know about one of the unhappy and controversial effects of long internet discussions, known as Godwin’s law? Long story short, it claims that:
“The longer the discussion, the higher the probability somebody mentions Nazis”
Unfortunately, such a mathematical formula truly exists.
To answer my rhetorical question from the subtitle: no, thank god, Code Reviews are a set of comments and discussions where this law does not apply 🙂.
However, like internet and social media discussions, Code Reviews can be LOOOOOONG. Many of us have such an experience: a sprint starts, our colleague makes a coffee, we take a task and start developing a new feature. First half of the sprint passes and thefirst “draft” Pull Request is created. And then it starts…
“Wouldn’t bar be a better name? No, I think foo describes it better. This method is way too long, can you split it? Please write tests for this class, it’s not covered. This library is deprecated, can you use the alternative one? Could you please…???”
Suddenly, after multiple Code Reviews with fixing andrefactoring iterations we realize the end of the sprint is coming and our QA staff will have to (again) work overtime to be able to test the feature before it goes to production.
Even though we want our developer teams’ knowledge shared, and to avoid knowledge silos and to ensure the quality of our code, and it’s really convenient to work fully remotely, the tool we often use for these — Code Reviews — can be ineffective.
This story happened recently on my project at Solargis, our innovative client at ableneo. A new senior developer came and one of his first tasks was to implement a rather complex, reusable UX/UI component. It was doable within one sprint, although significantly complex, but he was a senior, right? He should be able to do it and in case he implements something not according the team standards, other developers will point it out in their Code Review. However, the task was so complicated, the new developer (of course not his fault) was so unaware of the team code standards and requirements that after some time the number of comments in the Pull Request grew enormously. Additionally, since he was a senior, he had reasonable answers for the comments and explanations why he had developed something in a particular way.
All these factors resulted in not delivering the feature until the end of the sprint. After the sprint the priorities had changed and the Pull Request is still hanging in the team’s repository as this article is being published.🙃
So, how can we make the Code Review more effective and still utilize the benefits of inter-developer communication about the code they write day to day?
It’s simple: do not do Code Reviews 🙂
Or at least: do not do the majority of Code Reviews in the form of an internet discussion under a line of code.
Why would we write everything when we can just say everything? Ask everything? Directly consult anything?
This is when our good old friend, the Extreme Programming technique Pair Programming comes into the fore.
It’s an engineering practice recommended by authorities like Robert Martin or Martin Fowler to help the teams and the individuals to be on the same page.
Uncle Bob Martin on Twitter: "The true value of pair (or mob) programming is that it allows knowledge to spread quickly through the team. This shared knowledge is what makes the team a team. In a team, when a player goes down, the others cover the hole and keep moving towards the goal. / Twitter"
The true value of pair (or mob) programming is that it allows knowledge to spread quickly through the team. This shared knowledge is what makes the team a team. In a team, when a player goes down, the others cover the hole and keep moving towards the goal.
However, this article is not so much about what actually is Pair Programming and how to do it, but rather why to do it and what consequences it had in a real project.
At the same time of our unsuccessful delivery of our List component, we realized we have to face these challenges:
- Pull Request bottlenecks (undelivered List component)
- Dispersion due to pandemic remote work
- No onboarding process
- Knowledge silos (long-term employees with busy calendars)
All our collaboration work was happening in the Code Reviews, ad-hoc 1:1 or 1:N calls, so there was definitely teamwork. But why don’t improve it and standardize it?
We could see Pair Programming really addresses most of our problems when we looked at the benefits:
- knowledge sharing
- keeping focus on what is important
- reflection
- Code Review on-the-go (catching errors and bad design early)
- avoidance of superficial Code Reviews (“looks good to me”)
- avoidance of Code Review bottlenecks
- team building on-the-go
- tactical & strategical points of view at the same time
- collective code ownership
- faster and more effective onboarding of new team members
- avoidance of sunk-cost-fallacy (motivation to improve something gets weaker with time)
So, we decided to make an experiment: let’s pair by default for one sprint (in our case 3 weeks).
First, we agreed what type of tasks are suitable for pairing:
- complex code with unknown / unclear solutions (with prior research)
- volatile sections of the system
- critical systems
- core libraries
And what not:
- trivial tasks
- spikes, proof of concepts
Then, we decided who should pair with whom: senior-junior or junior-junior pairs make more sense than senior-senior from the knowledge sharing point of view.
Finally, the team set its measurement technique. Even though there are some studies that had attempted to measure effects of Pair Programming mathematically and compare it with individual programming, it’s another challenge to apply these measurements in non-laboratory conditions. Due to this we decided our measurement technique will be the team’s feelings and feedback after the experiment.
And that went quite well. At the retro after the sprint ended, among our approximately 10 team members, 6 reflected positively about our experiment.
One of my colleagues was so kind that he even wrote a complex feedback on his experience with pairing:
Went well:
I could think out loud
I could practice what I already know
I was corrected and received explanation when I said something incorrect
I received hints when I got stuck
I could see how the other person thinks, what tools they use and that helped me to optimize my work
Pair Programming has a benefit of instant meeting with my colleagues
To Improve:
I got disturbed when there are other people talking around my desk, because during the pandemic I was used to work alone
At the beginning it felt awkward to talk in front of other people, but later I got used to it
I did not have enough time to write what I learned from the other person and I kept forgetting it
After the experiment, the team realized that Pair Programming should be adopted as a new standard and since then, we pair on a daily basis. However, in order to do Pair Programming in a sustainable manner, there are some challenges that have to be solved:
Challenge: exhaustion (coding + communication = two tasks that require energy)
Solution: breaks, pairing for limited part of the day
Challenge: differences in coding styles
Solution: invest time to understanding, ask questions: how do we want to pair? give / receive feedback after the session
Challenge: interruptions caused by meetings, little individual time
Solution: proper planning
Challenge: losing focus
Solution: do not do anything else, no mobile phones
Challenge: different skill levels
Solution: it’s an opportunity to test more experienced developer’s abilities to explain, the less experienced can still see something what the more experienced may not
Challenge: power dynamics
Solution: be humble, be vulnerable, no keyboard hogging, no micro-management, let the other finish their thoughts (5 second rule)
Challenge: pairing when there are lots of unknowns
Solution: do spikes individually, make notes when you encounter unclear problems during the session
Challenge: confrontations about the effectivity of Pair Programming
Solution: patiently explain the benefits (maybe with this article 😎), show data, studies and community opinions, do an experiment and receive team’s feedback
Typical situation:
Business stakeholder: “Pair-Programming halves the productivity of developers.”
Martin Fowler: “That would be true if the hardest part of programming was typing”.
In conclusion, humans are social creatures. Even though part of the society can still perceive Software Developers as rather introverted people, I don’t believe it’s generally true. What I believe is that software development is by its nature team-based work. Therefore, Pair Programming is a great technique that can bring your programming & personal skills to the next level.
So, see you at our common desk. 😉
How to make Code Review more effective with Pair Programming was originally published in ableneo People on Medium, where people are continuing the conversation by highlighting and responding to this story.