Pair-programming makes light(er) work of sprint zero

By Kale-Ab Tessera (Entelect, Intermediate Software Engineer)

Software Engineers are notorious for being antisocial. We are known to work in isolation, with our headphones on and enough coffee and snacks to sustain us. However, with the increased adoption of Agile and Extreme Programming, pair programming has increased in popularity, challenging the lone-programmer mindset.

My team and I were challenged to deliver an MVP in 16 weeks for a large South African mobile communications company. The challenges included a tight timeline, high-quality delivery, acute and effective problem-solving and somewhere amongst all this, team growth.

Sprint zero is often the hardest – in order to develop a MVP, teams have to conduct client interviews, story mapping with UX designs, setup of the delivery pipeline for the squad, continuous Integration and delivery, deployments, identifying and implementing communication channels such as Slack, with integrations into the delivery pipeline.

Essentially, pair programming is where two people simultaneously working together on the same piece of code. One person (the driver) codes, while another person (the navigator) makes suggestions, corrections and improvements to the code written. These two roles can also switch at certain intervals allowing both individuals to get a chance at coding and, making suggestions.

We believed pair-programming would help overcome key challenges synonymous with ‘sprint zero’, such as distribution of knowledge, code quality, and team communication, but we uncovered some other benefits along the way too.

Adopting new technology and acquiring new skills

On this project, many of the team were new to React and Spring Boot. Pair programming allowed us to learn and rapidly distribute our knowledge in the team. Once someone had learned how a part of a framework works, he/she would pair with an individual who didn’t and this would quickly distribute the knowledge in the team, meaning in a few weeks, we all knew the fundamentals of the frameworks we were using.

Along with quick distribution of knowledge, this approach also reduces key man dependency, whereby only one individual knows how a certain part of a system works. Pair programming transforms the effectiveness of the entire team by ensuring at least two people have seen or worked through each part of the system. Distribution of knowledge also supports the development of high-quality code under tight deadlines.

Another advantage we had as a result of pair programming was increased project momentum. We have all been in situations where we have spent too much time stuck on a technical task. Rather than asking a coworker for help, we tend to push through and waste valuable time. Pair programming ensures that if one person is stuck or struggling, another person is able to help or is at least aware of the situation.

Maintaining code quality

Sixteen weeks is a tight deadline for any team to develop a MVP and makes achieving good code quality quite difficult. In addition to Unit, Integration and Acceptance Tests, pair programming allowed us to ensure quality was maintained as we coded in pairs and checked each other’s code and logic.

It is inevitable that having multiple people working on the same piece of code, increases the likelihood to pick up bugs earlier, while decreases the chance of using obscure hacks (two people need to agree to these hacks).

Furthermore, both parties can share their knowledge, tips and tricks with one another, creating a code base using the shared knowledge of both parties. Even the intern could teach you about some design pattern or tool he or she read about the night before.

Team communication

Effective team communication is a critical part of any successful project. Pair programming encourages individuals to discuss problems together and solve them in a way that both parties are happy. This also ensures a better spread of knowledge of what is going on in the system, ensuring that more people are in the loop with the inner working of the system and what the business requires.

This was especially relevant to our project, as it had complicated business rules, which the team needed to master quickly. When pairing, we would spread and build on our understanding of these complicated rules and we could discuss possible ways of representing these rules.

Working in tight-knit pairs and communicating closely also helps keep the teams focused. We found that it is much easier for a pair to stay highly focused for longer, than a larger team where people work as individuals and some people on the periphery fade away.

A perfect solution?

Naturally, there are risks too. The most significant risk with pair-programming that we have identified is slower development time. Research has shown that pair programming has a 15% development time cost (https://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF). This is because less tasks can be worked on concurrently. Additionally, whether it is due to different experience, skill levels or just programming speed, pair programming can also slow down the faster of the pair.

Additionally, Pair programming inherently involves a lot of discussion, but it is important to ensure majority of this talk is related to tackling the issues at hand. A major risk of pair programming, is having one person doing all the work or driving, while the other individual is disinterested or on their phones. This could lead to a wasted resource and no real value received from pair programming.

And we know that some engineers prefer working alone, so Pair Programming will be a big shift for some team members.

Undeniably, Pair Programming is an investment

Even with the possible risks of slightly slower development times, workload imbalance or off topic discussions, pair programming can increase quality of code and ultimately saves time and money.

Pair programming should definitely be viewed as an investment. The longer-term advantages of distribution of knowledge, code quality and bug fixes, along with team communication and problem-solving capabilities, converts a 15% development time cost, into an investment in the present and future capabilities of any team.

Teams still need to have the discipline and the people skills to make sure pair programming is beneficial. In situations where pair programming is not possible, teams could ensure thorough code reviews are done so that all code has been checked or at least seen by more than one person.

Is pair programming suited for your team? Well, maybe. It worked well for our team and allowed us to build a good quality MVP, with majority of the team having a good idea of the system as a whole. Why not give it a try?