.webp)
Programming Best Practices: It takes more than simply two people sitting in front of an IDE to pair program. These tried-and-true responses to frequently asked topics can help you choose a compatible partner.It's no secret that Philippe and I support Extreme Programming and its methods—Philippe more so than me, but I'll take part of the credit anyway. As a result, we were recently invited to take part in a Q&A session where we discussed our experiences and suggestions for using pair programming in a development team.
10 Best Practices for Effective Pair Programming
When should pair programming be done?
Even if they may not like to acknowledge it, every team engages in pair programming at some point! Pair programming is the practice of developers asking a colleague for assistance when they are stuck on a challenging piece of code or a problem. Why don't we use the four eyes approach constantly if we accept that it may speed up the solution of complicated problems?Returning to the original topic, some teams are always in love with pair programming! However, it can be simpler and preferable to begin cautiously. For instance, aim to pair 50% of the time during the upcoming sprint. Attempting Mob programming on a particular narrative is an additional possibility. Try it for a sprint and assess your experience in your subsequent retrospective. Go ahead and pair program full-time if you believe the team is prepared!
Read also: The Ultimate Ad Guide: Types of Social Media Ads You Need to Know
2. How should our team begin using pair programming?
Our data indicated that we were able to close the same amount of narrative points before and after pairing, thus at initially the velocity did not alter. However, after a few sprints, we began to worry more about raising the caliber of the code. For a while, the velocity decreased as we concentrated more on it, but we also succeeded in significantly lowering the number of faults and the amount of time needed for code review. We can claim that, in the long term, our production rose!Lastly, it's crucial to note that our team's productivity remained unaffected by the departure of any team members—even senior ones—thanks to pair programming and knowledge sharing!
Setting the agenda for the next retrospective to specify the team's pairing agreement should come first. This comprises:
- How much time should I spend pairing?
- How should the pairings be arranged?
- How should the tales be distributed?
- When should you take over as the navigator and driver?
3. For what duration do we pair?
Certain teams have a daily or semi-daily partner swapping schedule. While sharing information across team members may be a good idea, it doesn't always function as planned since it may take some time for the story lead to fully onboard their partner on the responsibilities and goals of the tale. As a result, finishing the tale can take longer.We used to rotate pairings in our squad either every week or according to the tale.During the sprint and mid-sprint planning sessions, we used to arrange the tales and pairings on a weekly basis. Even if the storylines weren't closed yet, we used to reorganize the during those sessions. We made sure that no couple worked together for more than a week by doing this.Once a narrative was over, the second option included exchanging couples. One couple would end their narrative during the daily standup and inquire whether any other pairs would be interested in exchanging partners.Changing pairings often is important for a number of reasons. Strengthening the bonds between team members and minimizing disagreements that may occur when two developers collaborate for an extended period of time are two of those factors.
4. When are the pairings scheduled?
Pair planning is a fantastic idea for the "sprint planning" and "mid-sprint review" sessions. We used to decide on the pairings and the story each pair will work on next after reviewing all of the pending tales (Not Started & InProgress) from the sprint. We had one of those sessions every week because our sprint lasted for two weeks, which was perfect for pair planning.
Read also: The Ultimate Guide to Launching a Crowdfunding Campaign
5. How will the stories be divided?
Each duo should focus on a single tale, which entails cooperating on all of the assignments. When assigning the stories to the pairings, two factors must be taken into account.Make sure that each team member is contributing to the various code modules first. You encourage shared code ownership among the team members by doing this.Second, one of the two people has to be conversant with the other's code as well as the activities required to wrap up the narrative. Pairing will undoubtedly aid in distributing information across team members, therefore this problem will eventually become less of one!
6. When you pair programme, what are the best practises you follow?
By trial and error and gathering input during retrospectives, we developed our best practices. Of course, each team will have different best practices.
The following are four excellent practices that our team has implemented:
- Alternate between the navigator and the driver often. The likelihood of the navigator losing interest in and concentrate on the tale increases if this isn't done.
- Send in the code as often as you can. This technique ought to be used consistently, not only during pair programming. However, you may use this method as a motivator to often alternate between the navigator and the driver, particularly while partnering remotely.
- Maintain a current shared document with the tasks for the tale.This might be a mental map, a word document stored on Google Drive or Sharepoint, or simply a to-do list.
- When there is something you are unsure of, don't be hesitant to ask for clarification.
- When you're fatigued, don't be hesitant to ask for a break.
7. Do we work in pairs on intricate tales? or every story?
We believe that all tales should use pairing. Only in extremely rare circumstances did we choose not to pair. A pair can discover a better solution than a lone developer, even for tales that would be deemed "silly." Examples of this include factorization, suggesting a new tool, automating certain activities, etc. One effective technique to identify and execute refactoring is to pair on all production stories.If you're uncomfortable being paired all the time, give yourself ample alone time to maintain a steady pace.
8. In the event that we had wait an hour for a build, what would we do?
The guideline for extreme programming is that a build should not exceed ten minutes in duration. However, in practice, some projects require significantly more time to develop because of old code, module compilation, etc.Consider how pair programming may shorten build times rather than preventing you from pairing during a lengthy build! Here are some suggestionsThe four-eyes method makes it simpler and quicker to find problems when developing code and before submitting it to the build process! This will increase the likelihood that your build will pass.
Discuss how to enhance the construction while you wait for the lengthy build process to be completed. Our group was able to reduce the construction time from nine to three minutes.
Read also: Launch to Success: Your 2024 Guide to Starting a Thriving Small Business
9. How do we address the pair's differing levels of knowledge?
Knowledge exchange among team members is one of the main advantages of pair programming. Even yet, some developers—particularly senior members—will continue to know more about a given set of code modules. When the two have different levels of understanding, the driver should act as the navigator's coach. Although this might cause a delay in the story's conclusion, it will undoubtedly introduce the less experienced developer to the code much more quickly.
10. How should we handle the two cities' different time zones?
We find your question intriguing as it has to do with using pairing programming in remote mode! The authors of Extreme Programming Explained, Kent Beck & Cynthia Andres, advise having the team gather in an open area to sit together. Due to our distribution between Beirut and Paris, we were unable to do it. We choose to attempt pair programming in remote mode rather than to remove XP! We were successful for four years!To tell the truth, it wasn't simple at first! But with perseverance, gathering input during retrospectives, and trial and error, we were able to make it work.
- One of the challenges we encountered during remote pairing was the time difference between Paris and Beirut. The following are some of the agreements we came to that enabled us to solve this issue:
- Maintain a current shared document with all the tasks for the tale. If any of the two takes a cursory glance at the paper, they should be promptly informed on the story's progress.
- When you leave your desk, don't leave any uncommitted code behind! To organize your uncommitted code in Git, make a branch; in Perforce, use the shelf function.
- The two exchange calendars every morning so that they know when their individual meetings are scheduled.
- Take advantage of the time difference to complete whatever independent paperwork you have.