Monday 17 January 2011

Pair Programming

Pair programming is an agile software development technique in which two programmers work together at one workstation, or, remotely, through screen sharing.

The two programmers share two roles: driver and navigator. These two roles are alternated between the two at given time periods. The driver types the code while the navigator reviews each line of code as it is typed in. The navigator also identifies problems, concentrates at the overall design, so he focuses on a higher abstraction level then the driver, who is responsible for the syntax, semantics and algorithm.

A study shows that pair programming reduces the bugs present in the code by 15%-50%, although the programming time is slightly bigger. Even having the code delivered in a longer time than in the case of a single programmer, the time and costs spent for fixing the bugs are highly reduced.

As programmers work together, knowledge passes from one to another, and they pick up techniques and practices from each other.

Pair programming can be considered a social skill, and it can take some time to learn. Most often, the two programmers are not at the same level of discipline and knowledge and the higher one tends to become a mentor. Teacher-student relationship is not what pair programming is all about, some developers are poor teachers, but communicating, even if it can be avoided, and discussing ideas and possibilities is the key in pair programming.

With time, the two programmers will become more confident with the code they write, the knowledge base inside the team will increase, the productivity will increase and time management will improve.

An important factor in gaining knowledge is that the pairs should switch off regularly. This way, pairing spreads several kinds of knowledge throughout the team with great efficiency.
Many non-agile teams do not use pair programming at all and studies show that “islands of knowledge” tend to accumulate. Individual programmer tends to know a lot of important things that others are not aware of. If one of these islands leaves the team, gaps are likely to appear in the team, and projects tend to be delayed or worse, canceled.

A pair programming theory shows that by spreading large knowledge base widely within a team, exposure to staff turnover threat is reduced. In Extreme Programming, the Truck Number is described as the number of team members that would need to be hit by a truck to kill the project. Extreme Programming projects strive to keep the Truck Number as close as possible to the total team size. So if someone leaves, there are usually several developers that know something about the specific project.

No comments:

Post a Comment