Paarprogrammierung

Bei der Paarprogrammierung, auch Tandem-Programmierung, (englisch pair programming) programmieren zwei Personen gleichzeitig am selben Code bzw. Programmierproblem. Es ist eine Arbeitstechnik, die sich häufig bei agilen Vorgehensweisen zur Softwareentwicklung findet. Sie ist ein wichtiger Bestandteil von Extreme Programming (XP).

Bei der Erstellung des Quellcodes arbeiten jeweils zwei Programmierer gleichzeitig an einem Arbeitsplatz: Einer schreibt den Code, während der andere über die Problemstellungen nachdenkt, den geschriebenen Code kontrolliert sowie Probleme, die ihm dabei auffallen, sofort anspricht.^[1] Diese können dann sofort im Gespräch gelöst werden. Die beiden Programmierer sollten sich in den beiden Rollen abwechseln. Auch die Zusammensetzung der Paare sollte sich häufig ändern.

Eine Voraussetzung für Paarprogrammierung ist ein gemeinsam vereinbarter Programmierstil des gesamten Teams.

Zunächst soll Paarprogrammierung die Softwarequalität steigern. Durch die Kontrollfunktion der zweiten Person sollen problematische Lösungen vermieden werden. Die Paarprogrammierung dient aber auch zur Verbreitung von Wissen über den Quellcode. Durch das regelmäßige Rotieren der Partner kann immer der jeweils neue Partner durch Learning by Doing etwas über die bearbeiteten Quelltexte lernen.

Paarprogrammierung sollte nicht mit Mentoring oder Training verwechselt werden. Bei der Paarprogrammierung geht es um Zusammenarbeit auf Augenhöhe und ein Problem gemeinsam als Gleichgestellte zu lösen, auch wenn die Erfahrung der Partner unterschiedlich sein mag. Dagegen zeichnet sich eine Training/Mentoring-Beziehung durch ein klares Lehrer-Schüler-Gefälle aus.^[2] Studien zeigen, dass die Codequalität vor allem bei Paarungen von Junior mit Junior oder Fortgeschrittene mit Fortgeschrittene, aber nicht bei Paarungen von Senior mit Senior steigt.^[3]

Dieser Artikel oder nachfolgende Abschnitt ist nicht hinreichend mit Belegen (beispielsweise Einzelnachweisen) ausgestattet. Angaben ohne ausreichenden Beleg könnten demnächst entfernt werden. Bitte hilf Wikipedia, indem du die Angaben recherchierst und gute Belege einfügst.

Weniger Fehler

Paarprogrammierung führt zu weniger Fehlern und somit zu weniger Fehlerbehebungsaufwänden. Üblicherweise rechnet man bei Paarprogrammierung mit 15 % weniger Fehlern als bei herkömmlicher Programmierung.^[4]

Kleinere Programme

Paarprogrammierung führt im Schnitt zu um 20 % kleineren Programmen.^[4]

Höhere Disziplin

Paare entwickeln viel eher an der richtigen Stelle und machen kürzere Pausen.

Besserer Code

Bei der Paarprogrammierung entwickelt man sich weniger leicht in Sackgassen und erreicht so eine höhere Qualität.

Belastbarerer Flow

Paarprogrammierung führt zwar zu einer anderen Art von Flow, ermöglicht diesen aber eher als der konventionelle Ansatz: Ein Programmierer kann seinen Partner jederzeit nach dem aktuellen Stand fragen und dort anknüpfen. Unterbrechungen werden auf diese Art besser abgewehrt.

Freude an der Arbeit

Paarprogrammierung ist oft spannender und interessanter, als allein zu arbeiten. 90 % der Entwickler, die Paarprogrammierung betreiben, sprechen von einer erfreulicheren Arbeit.^[4]

Geringeres Risiko

Wenn das gesamte Projektteam mit der Methode Paarprogrammierung arbeitet und die jeweiligen Partner oft wechseln, erlangen alle Wissen über die gesamte Codebasis. Dies wiederum führt zu einem geringeren Projektrisiko hinsichtlich Mitarbeiterfluktuation und Mitarbeiterabwesenheiten, welche zu den größten Projektrisiken zählen^[5]. Es erhöht somit die Truck Number.

Wissensvermittlung

Jeder hat Wissen, das andere nicht haben. Paarprogrammierung ist eine Möglichkeit, dieses Wissen zu verteilen oder auch zu transferieren.^[6]

Teambildung

Die Leute lernen sich gegenseitig schneller kennen, wodurch die Zusammenarbeit verbessert werden kann.

Weniger Unterbrechungen

Paare werden seltener unterbrochen als jemand, der allein arbeitet.

Teamfindung

Teamfindung kann aufwendig sein, wenn nicht alle Personen miteinander produktiv arbeiten können. Eingewöhnung der Teammitglieder kann Zeit erfordern.

Urheberrecht

Es kann wie bei allen nicht von Einzelpersonen entwickelten Werken das Urheberrecht nicht für einzelne Personen angewandt werden.

Haftung

Es kann wie bei allen nicht von Einzelpersonen entwickelten Werken zu Konflikten kommen, da später nicht unbedingt klar ist, wer für fehlerhaften oder urheberrechtsverletzenden Code haftet.

Paarprogrammierung führt zu einer geringeren Geschwindigkeit bei der Programmierung. Bei einer Studie benötigten die Paare 15 % mehr Zeit gegenüber der Geschwindigkeit einzelner Personen.^[4] Befürworter der Paarprogrammierung behaupten, dass die Produktivität durch diese Vorgehensweise nicht sinke, sondern im Gegenteil sogar deutlich steige. Grund dafür sei, dass die durch Paarprogrammierung gesteigerte technische und fachliche Qualität genau dort die Produktivität erhöhe, wo während der Softwareentwicklung am meisten Zeit verbracht wird: Beim Fehlerfinden und -beheben sowie beim Lesen von Code. Üblicherweise geht man davon aus, dass Fehler, die erst im Test gefunden werden, zehnmal so teuer in der Behebung sind, als wenn sie bereits während der Entwicklung gefunden werden.

Voraussetzung für hohe Produktivitätssteigerungen durch Paarprogrammierung ist allerdings, dass die fachliche Kompetenz der Partner nicht zu sehr voneinander abweicht.^[3][7]

Verteilte Paarprogrammierung (Distributed Pair Programming, DPP) ist die softwaregestützte Durchführung von Paarprogrammierung an getrennten Computern beispielsweise an unterschiedlichen Orten. Bekannte Werkzeuge für verteilte Paarprogrammierung sind Saros^[8], XPairtise^[9] oder „Code With Me“^[10].

• Laurie Williams: The Collaborative Software Process. (PDF; 591 kB; englisch)
• Tilman Walther: Pair Programming. (PDF; 239 kB)
• Chih-wei Ho et al.: Sangam – A Distributed Pair Programming Plug-in for Eclipse csc.ncsu.edu (PDF; 200 kB)

1. ↑ Kent Beck: Extreme Programming Explained. Embrace Change. 2. Auflage. Addison-Wesley Longman, Amsterdam 2004, ISBN 978-0-321-27865-4, Kap. 10, S. 58 (englisch, "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. ↑ Pair Programming. In: extremeprogramming.org. Abgerufen am 22. Oktober 2025. 
3. ↑ ^{a b} Medium.com: In-Depth: The Costs And Benefits Of Pair Programming, abgerufen am 22. Oktober 2025
4. ↑ ^{a b c d} Alistair Cockburn, Laurie Williams: The Costs and Benefits of Pair Programming. In: University of Utah Computer Science (Hrsg.): Extreme programming examined. Addison-Wesley, 2001, ISBN 0-201-71040-4, S. 223 - 243 (ncsu.edu [PDF; abgerufen am 10. November 2013]). 
5. ↑ Tom DeMarco, Timothy Lister: Bärentango. (Original: Waltzing With Bears) Hanser Fachbuchverlag, Leipzig 2003, ISBN 3-446-22333-9
6. ↑ tagesspiegel.de Lutz Prechelt: Wissen vereinen: Verteilte Paarprogrammierung, In: Tagesspiegel, 2. November 2015.
7. ↑ Sarah Mei: Pairing with Junior Developers. In: madeintandem.com. 2015, abgerufen am 22. Oktober 2025 (amerikanisches Englisch). 
8. ↑ Saros – Distributed Collaborative Editing and Pair Programming. Arbeitsgruppe Software Engineering, FU Berlin (Website)
9. ↑ XPairtise - A Distributed Pair Programming Plug-in For Eclipse. The XPairtise Team (Website)
10. ↑ Code With Me: The Collaborative Programming Service by JetBrains. Abgerufen am 20. Oktober 2021 (englisch). 

• Quietscheentchen-Debugging (Stichwort Rubber duck)