From the course: Agile Software Development
Pair programming
- Pair programming is one of the key practices of Extreme Programming. In pair programming, two developers sit at a computer terminal, one writes code while the other views the monitor. The second person constantly reviews the code as it is being developed, asks questions about the implementation, and assists the first developer with code suggestions. The two developers switch roles periodically and the process continues. When I was first introduced to pair programming, I had two major concerns. If two people are working on the same item at the same time, isn't this the equivalent of reducing our team size by 50 percent? And some people work more productively alone, why do they need to have another person working with them? My mentor at that time explained that the benefits of pair programming far outweighed my concerns. Firstly, pair programming provides immediate and constant peer review feedback. As a result, code quality improves without the additional time usually spent on scheduled peer review sessions. Another pair of eyes at the same terminal is greatly beneficial. Pair programming does not necessarily mean the pairs are fixed. Agile teams continually change pairs, and this greatly improves team communication. Individuals with different backgrounds and experience often communicate useful information to their partners that they would otherwise not be exposed to. Pair programming facilitates knowledge sharing, and when discussing knowledge sharing, it's important to consider the two types of skill workers. The first type called I-shaped people are individuals that have deep knowledge in a very narrow area of skills. The second type are called T-shaped people. They also have deep knowledge in a certain range of skills, but they also possess some knowledge in a wider area of skills. An example of a T-shaped person is someone who is good at business analysis and also has useful knowledge of software design and test automation. Pairing people with different types of skills helps members become more T-shaped. Another key benefit of pair programming is that when we work in pairs, we are less inclined to spend time on personal distractions such as checking emails, stock market prices, sports scores, et cetera. Less distractions means teams are more productive and better focused. What about the concern with personal space? Many people prefer to work alone, however, you can address those concerns by citing the statistics that show pair programmers to be more productive and write better quality code. Hopefully, this will make them feel more inclined to embrace pair programming. If this does not address their concerns, have your team try pair programming as an experiment for a few days. Look at your project quality metrics, such as defects per feature, and this may convince the team to continue with pair programming. They could even switch to pair programming on certain days of the week or certain parts of the day when they feel they will be productive in a pair. Because Agile teams use bottom up intelligence, the decision to adopt or reject pair programming should be left to the team.
Practice while you learn with exercise files
Download the files the instructor uses to teach the course. Follow along and learn by watching, listening and practicing.
Download courses and learn on the go
Watch courses on your mobile device without an internet connection. Download courses using your iOS or Android LinkedIn Learning app.