Introduction
Whilst working in India, I had to persuade our development team why we should pair program and what benefits it is currently giving our UK Teams. Here are a few of my thoughts used to persuade our development team, enough to give it ago.
Pair programming is where two developers work on the same machine. One person is the driver, the other the navigator. The driver performs the coding whilst the navigator is continually reading, spell-checking and reviewing the driver’s code; continually offering input and thinking through problems.
These roles are by no means fixed; the roles should be changed frequently, perhaps every hour or after a particular task. If a test driven approach is being practiced, then a good way is to get one developer to write the test and the other the implementation; after the test passes the roles are then swapped, continually taking it in turns. If the driver finds a problem then there are two people to find a solution; typically two peoples input are better than one.
Benefits
No two people are the same. This means that when pairing with someone it is likely the people will specialise in different things (in terms of technology and systems knowledge). These skills are then transferred, proving a useful learning aid to one-another and having twice the skill to tackle the task. This results in two developers being fully aware of the code and why it was implemented in that way.
Due to the constant review performed by the navigator, the chances are the code will be of a higher quality, every action must be justified to the other person in the pair and it is recommended that both parties question each other’s actions in a constructive way. It is less likely to contain bugs and hacks that can cause maintenance problems later on and the developer will not be able to take short cuts, because both people have ownership which means both peoples reputation is on the line. The code is often leaner and more precise because there are two people thinking of the best way to write the code, often one will have a better idea than the other; and of course these ideas will be interchanged throughout.
Quite often there will be a senior and junior developer paired, whilst this is great, two junior developers will still reap the benefits of pair programming. The idea is not for the senior developer to preach to the junior developer, it is a collective effort and there will be times when the junior will come up with a better way of doing things. Both parties will learn something from one another, the senior developer can also improve on his or hers coaching skills at the same time. Just because a person is senior, it does not mean they have a laid back role to play and nor are they always right. Pair programming will also make the senior guy know his stuff, because the junior developer is encouraged to ask questions.
The communication and team building aspects are strong advantages to pair programming; it gets developers talking and communicating ideas. Pairing may be an invasive practice, although it can force a level of communication that would be hard to achieve through other methods. Pair programming is also fun because it helps to build relationships and improve team moral.
Collective Ownership protects the companies investment, because it increases the bus factor (if one person gets hit by a bus, you still have other people that can maintain the code). It has potentially serious consequences if only a single person can maintain a section of code.
Collective ownership is also a great benefit to the developer. Previously they were responsible for a small chunk of code, where as now they can take collective ownership for the entire application, giving the developer a sense of being a part of something.
Maintenance would be easier because you have a minimum of two developers that know the system.
Pair programming is not about one guy doing the work and the other sitting there falling asleep at the wheel, it is about a continual dialog between the two pairs. Quite often the response from management is productivity is cut in half; however this is not the case. The code productivity is actually increased because developers can keep their focus for longer, because one of the pairs is right their keeping the other alert and productive- a constant monitoring in a friendly way! There is little chance to get distracted to check your emails for an hour or browse the internet because the other pair won’t find that interesting.
It is also advisable to change machines often to shake things up and indentify potential deployment issues. It is important that every developer has their environment setup in an identical fashion, to ensure that it is seamless when you move from machine to machine.
Summary
Finally, pair programming has a positive impact on development projects when done properly. It positively improves the team by building and strengthening relationships. It encourages coaching and learning between both pairs and addresses matters of code ownership, protecting the companies investment. It improves the code base in terms of quality and ensures that it is always reviewed by a member of the team, reducing the likelihood of silly mistakes or potential bugs