Pair Programming: Pros and Cons
- Jun 07, 2015
- By kirthi
- In Uncategorized
- Share on
Pair programming refers to an agile software development technique where two programmers work together at one workstation. One of them puts together the code, and the other functions as an observer or navigator, testing and reviewing each line of code in real time, as it is typed in. The two programmers tend to work interchangeably, where they switch roles throughout the process.
In the course of reviewing the code as it is produced, the observer looks at the code with an eye on the strategic direction of the task. Alongside review, therefore, the observer makes sure to craft ideas for the sake of improvements, and to ensure that there are means and ways in place to tackle future issues that may come up. This lets the driver – or the one who writes the code, to focus all their attention solely on the tactical side of completing the task on hand, while making use of the observer as a guide and as a safety net to fall back on.
The process of pair programming has a great deal of advantages. Primarily, it is a smart way to share knowledge and bring together the expertise of different developers. The constant hum of conversation between the developers ensures that they learn new concepts, and evolve in their thinking with each other’s influences playing a role for their own advancement. In the process, the developers increment personal growth. When a new developer joins the project and pairs with one of the old ones, the extent of knowledge transfer can be tremendous. There is virtually no loss in time, given that there is a speedy transfer of knowledge in place.
Secondly, pair programming facilitates the best of expertise and the greater combination of multiple talents and kinds of expertise. It is an intensive process that allows both to think together until there is a solution in place. Therefore, there is a strong degree of focus in place.
The third advantage of pair programming is that there is a safety net of sorts, that captures errors and offers a backup in real time – just as the code is being developed. That way, the review process is built into the development process, and makes the transitions smoother. Finally, the ease of correcting errors, mistakes and bugs is at hand with pair programming. A solo programmer may have a situation on hand when he faces a block, and finds himself challenged with the lack of a solution. When there is so much focus on a task, it is fully possible that all that attention on the task may force an individual to miss out on a solution. But in pair programming, since there is an obvious source of help on hand in the form of a pair of fresh eyes that is spending time only to review each line, the solutions are usually faster and easier to come by.
On the flipside – of course, it is not all hunky dory – there are many disadvantages to pair programming. Primarily, the sheer fact that it is an intensive process and starts from a prior platform of minds meeting each other – and it can be exhausting to expect a level playing field and not finding it in place. Programmers come from a place of expertise and experience, and they have their own talents that come to the table with their involvement. There is every likelihood of one-upmanship, and an attempt at trying to prove which one’s ways are better than the other. The locking of horns owing to ego can be a dangerous thing to the task on hand. Ego may force the driver and observer dynamic to wither away, as the observer’s suggestions may not be taken in the right spirit. A second issue is the availability of the individual programmers. Given that the driver and the observer have to sit together to deal with the task, the fact that each may have his or her own commitments, and their available times may not necessarily coincide, there could be interruptions in the smooth flow of the process.
Another common issue that is encountered in pair programming is that there is a lack of trust. It is possible that the developers may not be willing to reveal any hacks they may have come up with, or it is possible that they may come up with a solution quicker if they were working solo than together – and are not able to do that for want of consensus and teamwork. The element of teamwork is vital and an absolutely non-negotiable prerequisite for pair programming to work. Finally, there is also the question of clashes in ways of doing things. When there is a switch between the observer and driver, there should be an approach of empathy in the new roles. A driver must understand what he felt like when he was being observed in the process, and the observer must understand what he expected while he was driving the process. Without that understanding and prior state of empathy, the project might go haywire and maybe difficult to achieve, or may even reach an impasse.
The end result in a pair programming development process really depends on the process itself. While it has its own advantages and produces results if it succeeds, pair programming is really nuanced and heavily hinges on the programmers themselves, and their comfort levels in working together. There is no one size fits all approach when it comes to pair programming, and individual programmers vary as much as chalk and cheese: but the key is to look at it on a case by case basis.
Pair programming works very well when the pair of programmers share a great rapport, and come to the table with an open mind as to the other’s skills and trust in the other’s abilities. Ego has no room to play in a pair programming project, especially seeing as how there has to be some semblance of cooperation in the process.