Ist Pair Programming am Stand der Technik

Pair Programming ist eine Arbeitstechnik der agilen Softwareentwicklung die in den 1990er Jahren mit Extreme Programming eingeführt wurde und bereits seit den 2000er Jahren breite Verwendung findet.
Ist Pair Programming somit am Stand der Technik? Darf bzw. muss man es überall einsetzen? Ist es vielleicht schon längst durch modernere Arbeitstechniken wie Mob Programming überholt?

Um diese Fragen korrekt beantworten zu können, muss man nicht nur wissen, was Pair Programming genau ist und welche Alternativen es dazu gibt, was die Klausel "Stand der Technik" bedeutet und welche Verpflichtungen sich daraus ableiten. Man muss (gegebenenfalls sogar vor Gericht haltbar) nachweisen können, warum die Antworten nur so und nicht anders lauten können. Hier der diesbezügliche Nachweis basierend auf dem bereits früher vorgestellten gerichtlich haltbaren Prüfschema:

1. Beruht Pair Programming auf wissenschaftlichen Erkenntnissen?
2. Ist die Funktionstüchtigkeit von Pair Programming erprobt und erwiesen?
3. Ist Pair Programming fortschrittlicher als alternative Verfahren?
1. Andere Verfahren ermitteln, die anstelle von Pair Programming passen.
2. Verfahren ausscheiden, die nicht den Anforderungen einer Regel der Technik entsprechen.
3. Verfahren ausscheiden, die keinen wissenschaftlichen Ursprung haben.
4. Verfahren ausscheiden, deren Funktionstüchtigkeit nicht erprobt und erwiesen ist.
5. Aufwand und Ausmaß der Interessenverfolgung ermitteln (Kosten/Nutzen)
6. Verfahren ausscheiden, wo Verhältnismäßigkeit zwischen Kosten und Nutzen geringer 

ad 1.) Beruht Pair Programming auf wissenschaftlichen Erkenntnissen?
Unabhängig von Pair Programming gibt es jede Menge wissenschaftliche Erkenntnisse, die darauf hindeuten, dass durch Zusammenarbeit bessere Ergebnisse erzielt werden könnten als durch einzelne Individuen.¹ Darüber hinaus gibt es auch wissenschaftliche Erkenntnisse zu Pair Programming selbst.² Man kann also zu Recht davon ausgehen, dass Pair Programming auf wissenschaftlichen Erkenntnissen beruht. ✔

ad 2.) Ist die Funktionstüchtigkeit von Pair Programming erprobt und erwiesen?
Zur Überprüfung der Funktionstüchtigkeit muss zunächst gesagt werden, welcher Funktion, also welchem Zweck,  Pair Programming dient. Dient Pair Programming nur allgemein der Programmierung oder - wie oft behauptet - (auch) i) dem Wissenstransfer, ii) der Fehlervermeidung oder iii) der technischen Qualität? In all den behaupteten Funktionen ist also nachzuweisen, dass Pair Programming diesbezüglich nicht etwar nur beispielhaft erprobt, sondern auch tatsächlich erwiesen ist:

Da Pair Programming schon weltweit jahrzehntelang in Einsatz ist, gilt es hinsichtlich der genannten Funktionalitäten mit Sicherheit als erprobt. Gilt die diesbezügliche Funktionstüchtigkeit aber auch als erwiesen? Kann mittels Pair Programming erwiesenermaßen programmiert, Wissen transferiert, Fehler vermieden und technische Qualität des Codes verbessert werden? Dass man damit programmieren kann muss nicht bewiesen werden, da Pair Programming zweifelsfrei der Programmierung dient. Hinsichtlich der anderen Behauptungen lässt sich basierend folgendes feststellen: Cockburn und Williams haben wissenschaftlich nachgewiesen, dass Pair Programming i) dem Wissenstransfer dient²ⁱ⁾, ii) zu weniger Fehlern²ⁱⁱ⁾ und iii) zu besserer technischer Qualität²ⁱⁱⁱ⁾ als Solo-Programming führt. Die Funktionstüchtigkeit von Pair Programming hinsichtlich Programmierung, Wissenstransfer, Fehlervermeidung und technischer Qualität gilt also als erprobt und erwieden. ✔

ad 3) Ist Pair Programming fortschrittlicher als alternative Verfahren?
Solo- oder Mob-Programming sind alternative Verfahren zu Pair Programming. Sie entsprechen beide (ohne Nachweis) den oben unter 3a bis 3e gelisteten Forderungen. Hinsichtlich Solo Programming sind beispielsweise die wissenschaftlichen Erkenntnisse von Cockburn und Williams aufschlussreich: Hinsichtlich Fehlern und technischer Qualität belegten sie, das Pair Programming fortschrittlicher als Solo Programming ist. Allerdings hinsichtlich Entwicklungsaufwand (ohne nachgelagerte Aufwände wie Test oder Bugfixing) wurde ein 15% Nachteil gegenüber Solo Programming festgestellt. Auf Grund der geringeren Fehlerrate und höheren technischen Qualität konnten sie aber belegen, dass der insgesamte Aufwand (sogar noch exklusive Wartungsaufwand) geringer ist. Andere Studien kommen zu vergleichbaren Erkenntnissen.³ Pair Programming ist gegenüber Solo Programming hinsichtlich Fehlerrate, technischer Qualität und Gesamtaufwand fortschrittlicher. ✔

Hinsichtlich Kosten/Nutzen von Mob Programming im Vergleich zu Pair Programming haben Wang und Manos die 2023 verfügbaren diesbezüglichen wissenschaftlichen Erkenntnisse folgendermaßen zusammengefasst:⁴ Mob Programmierung führt gegenüber Pair Programming zu weniger Stress, ist allerdings in Situationen schlechter, die intensive Zusammenarbeit und Wissensaustausch fordern. In ihrer eigene Forschung kamen sie zu dem Ergebnis, dass die Produktivität (im Sinne von umgesetzten Tasks) bei Pair Programming höher sei. Aber die Effizienz (wenig Bugs) variiere je nach Team während sie bei Mob Programming stabil hoch sei.⁵ Es gibt derzeit keine eindeutigen Hinweise darauf, dass Pair Programming fortschrittlicher oder weniger fortschrittlich ist als Mob Programming. ✔

Fazit: Pair Programming ist nachweislich auf einem höheren Stand der Technik als Solo Programming und auf einem zumindest gleichwertigen Stand wie Mob Programming. Es sollte daher wenn möglich immer statt Solo Programming eingesetzt werden.

___

1. beispielsweise Delarue, A., Van Hootegem, G., Procter, S. and Burridge, M. (2008): "Teamworking and organizational performance: A review of survey-based research", The International Journal of Management Reviews, 10(2), pp. 127–48: "the balance of the evidence supports the proposition that teamwork improves organizational performance" oder Michaelsen, L. K., Watson, W. E., Black, R. H. (1989): "A realistic test of individual versus group consensus decision making.", Journal of Applied Psychology, 74(5), pp. 834–839: "groups outperformed their most proficient group member 97% of the time. Furthermore, 40% of the process gains could not be explained by either average or most knowledgeable group member scores" ↩

2. Alistair Cockburn, Laurie Williams: "The Costs and Benefits of Pair Programming", University of Utah Computer Science (Hrsg.) ↩
    i) 9 Learning, pp. 6-8
    ii) 7 Continuous Reviews, pp.5-6: "pair programming reduces defects", "the resultinc code has about 15% fewer defects"
    iii) 6 Design Quality, pp. 5: "pairs not only completed their programs with superior quality, but they consistently implemented the same functionality as the individuals in fewer lines of code"
    iv) 4 Economics, pp3-4: "pairs spent about 15% more time on the program than individuals"

3. beispielsweise Hannay et al.: "The effectiveness of pair programming: A meta-analysis.", Information and software technology 51.7 (2009): 1110-1122., Williams et al.: "Strengthening the case for pair programming." IEEE software 17.4 (2000): 19-25. ↩

4. Yibo Wang, Andreas Manos: "Comparative Analysis of Programming Approaches in Software Development: An Emperical Study of Solo, Pair, and Mob Programming", 2023, URN: urn:nbn:se:lnu:diva-122307: "The comparison between mob and pair programming in articles suggested that the choice largely depends on the team's specific context and needs. For example, Dragos found that mob programming can lead to lower stress levels compared to pair programming, while Kattan et al. observed that pair programming can be more suitable for tasks that require a high level of collaboration", "In terms of productivity, mob programming exhibited a superior quality of work even though only one person was operating, while pair programming exhibited variability based on group dynamics." ↩

5. Hier - und auch bei anderen wenigen wissenschaftlichen Studien zu Mob Programming - muss aber auf die geringe Datenmenge hingewiesen werden. Die Erkenntnisse sind also mit Vorsicht zu genießen. ↩