Pair Programming

The pair programming process is a work methodology advocated by eXtreme Programming (XP). As the name implies, each programming unit consists of two developers on a single computer. We may incur in the wrong thought that it is a waste of human capacity, since there are two elements to accomplish one’s tasks. However this thought could not be further from reality.

It’s expected that a paired team will produce the same amount of code as would be expected from two individual developers, however with the added value of the code having higher quality. In an earlier article I wrote about the importance and the role of code review in software development. A process that also consumes time in the present moment but that allows us to gain time in the future through the greater maturity and quality of the code that will follow for production environments. If one chooses this methodology, it can be assumed that the code revision will already be present in the code developed by the pair of developers.

Each developer will have a specific role – the “driver” and the “navigator”.

This means, one writes code while the other reads and anticipates issues. The best matching occurs when the keyboard goes hand in hand without any of the elements clinging to their pre-set role. As you may see, pair programming has much of soft-skills has of technical skills. It is not easy for a developer to open hand from his opinion before testing it. Like all soft-skills, it is possible to develop it but it requires time and openness from the individual.

“Since I’m going to have two developers together, it’s best to join a senior together with a junior, so he can learn”.

You must be really careful with this line of thought. A mentorship relation is very different from a peer relation. If productivity is not meant to be reduced, the team should be made of competent, autonomous developers and at the same level.

There are companies that prefer to define the roles as “developer” and “tester”, this means that the “developer” should write code to pass the unit tests written by the “tester”. The team will change roles often and sometimes even in the same day. As you may figure out, this would be impossible if both developers weren’t at the same level.

Another indication that eXtreme Programming gives, “move people around”. It is important that pair programming teams switch elements regularly. With this we will prevent the emergence of “islands of knowledge”, which in the future may lead us to a technical debt if the holders of knowledge decide to leave the company – a phenomenon feared by any technology manager.

Thus we may realize that pair programming paired with an internal developers rotation we will obtain greater:

  • continuous flow of development and delivery,
  • dissemination of knowledge of the project’s codebase,
  • quality in the production code,
  • decrease of possible technical debts.