Pair programming
Last year my son and I started learning piano. After trying youtube videos and a piano learning app, we decided to go more structured and started with a private teacher. We both started at the same time but took lessons separately. Lessons are 45 mins, weekly once.
During the week we practice the assignments. Many of these practice sessions, we use the twin mode to practice simultaneously. This mode splits the piano into 2 parts with identical keys so that 2 players can sit and play simultaneously as shown below.
Very quickly I realised the similarity with what I was doing at work i.e. pair programming. Pair programming is a practice in which two developers work as a team on a problem statement, working on the same computer.
A year into piano learning, I thought it’s a good time to articulate pair programming using our piano learning methods as an analogy. Like all analogies, it is not perfect but helps to understand key points.
So here is how our pairing technique helped us.
Real time feedback — During practice sessions, since we both were playing the same piece simultaneously, if one of us played incorrectly, it would sound different and we knew instantly one of us was wrong. We sort it out and move forward. This real time feedback helped us immensely to progress faster. If we were not pairing, we would have to wait for the next lesson with the teacher which is a week later. This works when we both are making different mistakes. But how about the same mistakes because it will sound the same and we wouldn’t spot it. Teacher enters here.
Better value from the teacher — Our 45 mins lessons with the teacher are split in two parts
- Review what we have done in the last few sessions. This is where teacher would spot the same mistakes that slipped in pairing sessions
- New lessons.
By correcting each other’s mistakes in practice sessions, we saved the time spent on #1 and spent more time on #2. This helped us to progress faster. This highlights the value of real-time feedback. Earlier the detection, lesser the cost.
Healthy peer pressure — we had agreed on daily time slots for pairing sessions. So even if one of us were lazy or distracted, the other would nudge. This peer pressure helped us with rhythm, intensity and as a result productivity. Before pairing on many occasions, we either skipped or were casual.
Collective ownership, no tribal knowledge — One occasion, my friend wanted to record something. I wasn’t available last min. However, since my son had the context and he could help.
Collective intelligence — Although we paired in practice sessions daily, we also explored separately based on individual likings. Anything new that we explored, we would exchange. So collectively we brought more knowledge to the table. In the context of software development, this improves quality of solutions
Pragmatism — We realised that the things with fewer unknowns we could do individually so splitting, working separately and then getting together helped. In the context of software development, these could be tasks with standard steps or fewer unknowns. Alternatively it could be trying different ideas by splitting and getting back together to get to a solution. Guideline is to assess the unknowns and then take a call whether to go solo or pair.
Overall teacher was also surprised with the speed and quality of our learning. What we would have achieved going solo in a year, we could achieve in around 8 months.
Let’s transpose this to software development.
Purely from a cost perspective, it implies that going solo, you would have saved 25% for the same unit of work.
Solo — 1 person takes 12 months for a unit of work. So cost is 12 person-months
Pairing — 2 persons take 8 months for a unit of work. Cost here is 16 person-months
Hence (16–12)/16% = 25%. Now this number would vary based on the complexity and unknowns which is where pairing brings in more value.
Additional considerations for cost perspective
- Going solo implies that there is no real time feedback. This results in code reviews, more refactoring, more iterations of quality checks. This negatively impacts the solo mode.
- On the contrary, pragmatism in pairing positively impacts pairing mode.
Effectively savings with solo mode start diminishing. Let’s say 25% comes down to 10–15% in this instance. Let’s generalise and inflate in favour of solo, so the savings could be in the range of 20-30%.
Value of time — For this 20–30% savings, it would take 50% more time to market (12 months — 8 months). From business perspective, how do you value this saved time
- New business lost?
- Competitive advantage lost?
- Regulatory or compliance fines?
- Additional cost maintaining older systems?
These considerations could be far more important than the savings. Other intangible benefits are
- Quality of the outcome is better due to collective intelligence and real time feedback
- On the people front, pairing helps to build collective ownership of the software which helps to manage the impact of people unavailability or movement. It helps in mentoring the junior team members or people who are new to the project or tech stack.
In summary, the benefits outweigh the cost savings that going solo brings in complex and time sensitive projects.
Off- course there are projects where cost saving is more important. Hence pairing may not be viable e.g. projects where time to market is not a priority and has a short project shelf life.
As a side note, like every other practice, there are anti-patterns in pairing as well. Topic that deserves a dedicated discussion.
