Pair programming is an agile software development technique in which 2 developers pair up as a team working together at one workstation. Both have the same target and task to execute. One, the driver, writes the code while the other, the navigator or observer considers the “strategic” direction of the work, coming up with ideas for improvements and likely future problems to address. Developers switch the roles periodically. It takes up the name from extreme programming ; extreme coding since code is reviewed as each line is typed.
In past, the way I made sure of code quality was getting the code reviewed with peer. Infact code reviews is one of the best strategies of having clean code and pairing fits right in the spot allowing to continuously review code as and when it is typed.
I have seen project suffering for reasons like people dropping of from project, falling sick or going for vacation. Moreover in traditional development, not all developers would be familiar with code base. Some might be an expert in understanding and supporting one feature and not have any clue about the rest, which creates a huge dependency and what if such person drops of the project? I am sure someone would pick it up and start working. The bigger problem here would be the seamless continuity of work which greatly impacts completion of the project or features on time because to begin with the developer don’t have any clue codebase, change impacts , etc. Pairing comes here for rescue by having shared knowledge and context enabling developers to continue work seamlessly.
With shared knowledge, on-boarding a new developer on the team seems to be a easy and quick task.
Pairing helps for the better design. The developers must negotiate a shared course of action when a conflict arises between them. In doing so, they consider a larger number of ways of solving the problem than a single programmer alone might do. This significantly improves the design quality of the program as it reduces the chances of selecting a poor method.
Pairing enhances and support personal development. It may be tips of programming language rules, coding standards, design patterns usage or overall system design. Not just technical skills, it also helps to develop some interpersonal skills like providing feedback, better communication or respecting each individual idea or solution.
Shared knowledge among the team helps for the collective ownership. Anyone could step into resolving bug or supporting feature. True team collaboration, whether it is taking the credit for the success or embracing the failure.
Pairing enhances the engagement and focus. Number of things that can interrupt or distract a developer working alone is huge. When you are part of a pair, you become much more resilient to those interruptions because you’re both committed to the task at hand. You’re less likely to be interrupted by colleagues because they can clearly see that you and your partner are in flow, and you’ll more easily resist the temptation to check emails because you’re both committed to completing the task at hand
Pairing works great when combined with Test Driven Development (TDD), one of the practice of Extreme Programming
Pair programming halves the developer productivity which would be true if the hardest part of the job was typing. Pairing is more productive due to continuous code reviews which come up with better designs, make less mistakes, and make more people familiar with the code. All of these things offset having less people typing.
I dont need pairing because I know I wont like it . This might me initial hesitation without even trying the technique. I wasn’t comfortable when I started this but now it gives me lot of confidence when I pair on a task. Hours passively staring over someone’s shoulder in a corner cube isn’t pair programming. Make sure you have someone who really knows how coach you, so you can be sure you’re evaluating the real thing.
Its worth pairing only on complex code. How do we decide what is complex? Moreover a developer might be fixing good number of bugs or work on many chores in a day which is a good context to be lost. Going hybrid approach might bring team imbalance. For eg, no one wants to work on simple things. Its not good for any one person in a team to decide what is complex? Imposing or bossing around not good for team collaboration
I was lot hesitant when I first tried on pair programming on a task and didn’t knew the benefits it would bring on the table. After spending 6 months roughly, I feel lot more confident pairing on a task with a developer and feel confident about the solution provided. I am truly able to understand benefits of continuous review, shared knowledge, easy on-boarding, better design and quality, which works very good, both for business and development. My advice to developers or business is to go out and try adopting pair programming . I am sure it will change your perception on pair programming