Pair programming

from Wikipedia, the free encyclopedia
Pair programming

Pair programming , too: Tandem programming , ( English pair programming ) is a working technique, often at agile to procedures software development takes place. It is an important part of Extreme Programming (XP).

description

When creating the source code , two programmers work at one workstation at the same time: One writes the code, while the other thinks about the problem, checks the written code and immediately addresses any problems that occur to him. These can then be resolved immediately in conversation. The two programmers should take turns in the two roles. The composition of the couples should also change frequently.

A prerequisite for pair programming is a jointly agreed programming style of the entire team.

aims

First, pair programming should increase the software quality. The control function of the second person is intended to avoid problematic solutions. Pair programming also serves to disseminate knowledge about the source code. By regularly rotating the partners, the new partner can always learn something about the processed source texts through learning by doing .

Positive effects

This article or the following section is not adequately provided with supporting documents ( e.g. individual evidence ). Information without sufficient evidence could be removed soon. Please help Wikipedia by researching the information and including good evidence.
Less mistakes
Pair programming leads to fewer errors and therefore less troubleshooting effort. Usually, pair programming is expected to have 15% fewer errors than conventional programming.
Smaller programs
Pair programming leads to an average of 20% smaller programs.
Higher discipline
Couples are much more likely to develop in the right place and take shorter breaks.
Better code
In pair programming, it is less easy to develop into dead ends and thus achieve a higher quality .
More resilient flow
Pair programming leads to a different type of flow , but enables this more than the conventional approach: A programmer can ask his partner about the current status at any time and connect there. Interruptions are better warded off this way.
Enjoy working
Programming in pairs is often more exciting and interesting than working alone. 90% of developers who do pair programming say it is more enjoyable work.
Lower risk
If the entire project team works with the pair programming method and the respective partners change frequently, everyone gains knowledge of the entire code base . This in turn leads to a lower project risk with regard to employee fluctuation and employee absences, which are among the greatest project risks. It thus increases the truck number .
Knowledge transfer
Everyone has knowledge that others don't. Pair programming is a possibility to distribute or transfer this knowledge.
team building
People get to know each other faster, which can improve collaboration.
Less interruptions
Couples are broken up less often than someone who works alone.

disadvantage

Team building
Team building can be time-consuming if not everyone can work productively with one another. It can take time for team members to get used to it.
copyright
As with any work not developed by individuals, copyright law cannot be applied to individuals.
liability
As with any work not developed by individuals, conflicts can arise because it is not necessarily clear later who is responsible for incorrect or copyright-infringing code.

productivity

Pair programming leads to a slower programming speed. In one study, couples needed 15% more time compared to speeding individuals. Proponents of pair programming claim that productivity does not decrease as a result of this approach, but on the contrary increases significantly. The reason for this is that the technical and professional quality increased through pair programming increases productivity precisely where the most time is spent during software development: When finding and correcting errors as well as when reading code. It is usually assumed that errors that are only found in the test are ten times more expensive to fix than if they were found during development.

However, the prerequisite for high productivity increases through pair programming is that the professional competence of the partners does not differ too much.

Distributed pair programming

Distributed pair programming (DPP) is the software-supported implementation of pair programming on separate computers, for example at different locations. Well-known tools for DPP are Saros and XPairtise.

literature

Individual evidence

  1. ↑ Kent Beck: Extreme Programming Explained . Embrace Change. 2nd Edition. Addison-Wesley Longman, Amsterdam 2004, ISBN 978-0-321-27865-4 , chap. 10 , p. 58 (English, "There are two roles in each pair. One partner, the one with the keyboard and the mouse, is thinking about the best way to implement this method right here. The other partner is thinking more strategically: Is this whole approach going to work? What are some other test cases that might not work yet? Is there some way to simplify the whole system so the current problem just dissappears? ").
  2. ^ A b c d Alistair Cockburn, Laurie Williams: The Costs and Benefits of Pair Programming . In: University of Utah Computer Science (Ed.): Extreme programming examined . Addison-Wesley, 2001, ISBN 0-201-71040-4 , pp. 223-243 ( ncsu.edu [PDF; accessed on November 10, 2013]).
  3. ↑ Tom DeMarco , Timothy Lister: Bear Tango. (Original: Waltzing With Bears ) Hanser Fachbuchverlag, Leipzig 2003, ISBN 3-446-22333-9
  4. ↑ tagesspiegel.de
  5. ^ Saros - Distributed Collaborative Editing and Pair Programming . Software Engineering Working Group, FU Berlin ( website )
  6. ↑ XPairtise - A Distributed Pair Programming Plug-in For Eclipse . The XPairtise Team ( website )