Pair Programming

Bei der Paarprogrammierung (englisch pair programming), auch Tandem-Programmierung, programmieren zwei Personen gleichzeitig am selben Code bzw. Programmierproblem.[1][2] Es handelt sich um eine Arbeitstechnik, die bei agilen Vorgehensweisen zur Softwareentwicklung Verwendung findet. Die Methode wurde in den 2000er Jahren als Bestandteil des Extreme Programming (XP) bekannt.[3]

Zunächst ist für die Paarprogrammierung ein gemeinsam vereinbarter Programmierstil Voraussetzung. Dieser wird vor Beginn der Entwicklungsarbeit vom Team festgelegt. Bei der Erstellung des Quellcodes arbeiten sodann jeweils zwei Programmierer gleichzeitig an einem Arbeitsplatz: Einer schreibt beispielsweise den Code, während der andere über die Problemstellungen nachdenkt, den geschriebenen Code kontrolliert sowie Probleme, die ihm dabei auffallen, direkt anspricht.[4] Diese können dann im Gespräch gelöst werden, am Ursprung ihrer Entstehung.

Es wird empfohlen, dass die beiden Programmierer sich in der Rolle abwechseln. Auch die Zusammensetzung der Paare sollte gewechselt werden.

Paarprogrammierung sollte nicht mit Mentoring oder Training verwechselt werden. Bei der Paarprogrammierung geht es um eine „Zusammenarbeit auf Augenhöhe“, um ein Problem gemeinsam zu lösen, auch wenn die Erfahrung und das Wissen der Partner unterschiedlich sein mag. Dagegen zeichnet sich eine Training bzw. Mentoring-Beziehung durch ein Lehrer-Schüler-Gefälle aus.[2]

Paarprogrammierung soll frühzeitig und entlang der Entwicklung von Software deren Softwarequalität verbessern. Durch die Kontrollfunktion der zweiten Person sollen Probleme an der Codequelle 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. Studien zeigen, dass die Codequalität vor allem bei Paarungen von Anfänger mit Anfänger oder Fortgeschrittene mit Fortgeschrittene, aber nicht bei Paarungen von Experte mit Experte steigt.[5] Mit der Methode sind die folgenden qualitativen Erwartungen an eine gute Softwareentwicklung verbunden:[6]

• 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.
• Kleinere Programme: Paarprogrammierung führt im Schnitt zu um 20 % kleineren Programmen.
• 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.
• 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 Risiken zählen.[7] Es erhöht somit die Truck Number.
• Wissenvermittlung: Jeder hat Wissen, das andere nicht haben. Paarprogrammierung ist eine Möglichkeit, dieses Wissen zu verteilen oder auch zu transferieren.[8]
• 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: Teambildung 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 in der Regel zu einer geringeren Geschwindigkeit bei der Programmierung durch Einzelpersonen, d. h. die Produktivität wird durch die Methode eingeschränkt. In einer Studie benötigten die Paare 15 % mehr Zeit gegenüber der Geschwindigkeit einzelner Personen.[9] 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.[5][10][11]

Bei der sogenannten Verteilten Paarprogrammierung wird die Paarprogrammierung softwaregestützt an getrennten Computern, beispielsweise an unterschiedlichen Orten, durchgeführt. Bekannte Werkzeuge für verteilte Paarprogrammierung sind oder waren: Saros[12][13], Sangam[14], XPairtise[15] oder „Code With Me“[16] von JetBrains.

Seit etwa den 2010er Jahren findet diese „verteilte Programmierung“ und Absprache technisch entlang von Telearbeit und verteilen Versionsverwaltungssystemen wie Git statt.

• Liste von Softwareentwicklungsprozessen
• Quietscheentchen-Debugging
• Verifizierung & Validierung (V&V)

• Tilman Walther: Pair Programming. Ausarbeitung im Rahmen des Seminars Agile Softwareprozesse. FU Berlin, Berlin 2005 (tilman.de [PDF]). 

1. ↑ Laurie Williams: The Collaborative Software Process. 1999, abgerufen am 22. August 2026 (englisch). 
2. ↑ ^{a b} Don Wells: Pair Programming. 1999, archiviert vom Original am 19. Juli 2026; abgerufen am 22. August 2026 (englisch). 
3. ↑ K. Beck: Embracing change with extreme programming. In: Computer. Band 32, Nr. 10, Oktober 1999, ISSN 1558-0814, S. 70–77, doi:10.1109/2.796139 (englisch, ieee.org [abgerufen am 22. August 2026]). 
4. ↑ 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, archive.org – "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?"). 
5. ↑ ^{a b} Christiaan Verwijs: In-Depth: The Costs And Benefits Of Pair Programming. In: The Liberators. 15. März 2024, abgerufen am 22. August 2026 (englisch). 
6. ↑ 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]). 
7. ↑ Tom DeMarco, Timothy Lister: Bärentango. (Original: Waltzing With Bears) Hanser Fachbuchverlag, Leipzig 2003, ISBN 3-446-22333-9
8. ↑ Prof. Dr. Lutz Prechelt: Wissen vereinen: Verteilte Paarprogrammierung. In: Der Tagesspiegel Online. ISSN 1865-2263 (tagesspiegel.de [abgerufen am 22. August 2026]). 
9. ↑ A. Cockburn, L. Williams: The Costs and Benefits of Pair Programming. In: Computer Science. 25. Mai 2001 (englisch, umich.edu [PDF]). 
10. ↑ Sarah Mei: Pairing with Junior Developers. In: madeintandem.com. 2015, abgerufen am 22. Oktober 2025 (amerikanisches Englisch). 
11. ↑ Pairing with Junior Developers | Tandem. In: Tandem. 27. Januar 2015 (archive.org [abgerufen am 22. August 2026]). 
12. ↑ Saros. In: AG SE / FU Berlin. Abgerufen am 22. August 2026 (englisch). 
13. ↑ Stephan Salinger, Christopher Oezbek, Karl Beecher, Julia Schenk: Saros: an eclipse plug-in for distributed party programming. In: Proceedings of the 2010 ICSE Workshop on Cooperative and Human Aspects of Software Engineering (= CHASE '10). Association for Computing Machinery, New York, NY, USA 2010, ISBN 978-1-60558-966-4, S. 48–55, doi:10.1145/1833310.1833319 (englisch, acm.org [abgerufen am 22. August 2026]). 
14. ↑ Chih-Wei Ho, Somik Raha, Edward Gehringer, Laurie Williams: Sangam: a distributed pair programming plug-in for Eclipse. ACM, 2004, ISBN 978-1-4503-7798-0, S. 73–77, doi:10.1145/1066129.1066144 (englisch, acm.org [abgerufen am 22. August 2026]). 
15. ↑ XPairtise - Pair Programming for Eclipse. In: Sourceforge.net. 2008, abgerufen am 22. August 2026 (englisch). 
16. ↑ Sunsetting Code With Me. In: JetBrains. 16. März 2026, abgerufen am 22. August 2026 (amerikanisches Englisch).