Pro und kontra Paarprogrammierung

Bekannt geworden ist Paarprogrammierung (engl. pair programming) als Methode des Extreme Programming. Dabei sitzen zwei Programmierer vor einem Rechner und arbeiten gemeinsam an einer Aufgabe. Doch lohnt es sich, zu zweit an einer Aufgabe zu sitzen? Was spricht für und gegen die paarweise Programmierung?

Pro

• Fehler werden durch das Vieraugenprinzip reduziert. Dadurch verringert sich der Aufwand für separate Code-Reviews und Zeit für die Fehlerbehebung. Außerdem sind separate Code-Reviews tendenziell oberflächlicher und führen eher zu negativer Kommunikation.
• Der Code wird verständlicher, weil er sofort vom Partner auf Verständlichkeit geprüft wird.
• Das Design der Software wird besser.
• Das Wissen der Partner ergänzt sich – jeder hat andere Stärken und Schwächen. Wenn ein Entwickler nicht weiter weiß, kann ihm der andere helfen.
• Der Partner verhindert, dass sich ein Entwickler alleine an einer Entscheidung festbeißt. Beim Programmieren werden schließlich am laufenden Band große und kleine Entscheidungen getroffen.
• Wissen wird gut im Team verteilt und Wissensinseln werden verhindert. Neue Mitarbeiter finden gut in ein bestehendes System.
• Geringere Wahrscheinlichkeit, dass Aufgaben falsch verstanden werden.
• Gefahr, dass Entwickler sich mit anderen Dingen wie E-Mails ablenken ist geringer.
• Verbreitung von Konventionen wird gefördert.
• Die Gemeineinsame Verantwortung für den Code wird gefördert.
• Die Koordination im Team ist einfacher, weil nicht so viele Dinge parallel bearbeitet werden.
• Weniger Aufwand, die einzelnen Teilergebnisse zusammenzuführen.
• Es wird eine höhere Testabdeckung erreicht.
• Die Zeit zur Bearbeitung einer Aufgabe wird verkürzt, während die summierte Arbeitszeit höchstens leicht steigt.
• Mehr Spaß bei der Arbeit.

Kontra

• Bei manchen Aufgaben ist die paarweise Bearbeitung Zeitverschwendung. Aber es spricht nichts dagegen, wenn solche Aufgaben trotz sonst überlicher Paarprogrammierung alleine bearbeitet werden.
• Paarprogrammierung kann anstrengender sein, weil man mehr fragen, erklären und seine Ideen verteidigen muss.
• Bei zu großen Leistungsunterschieden wird der bessere der beiden Entwickler zu stark ausgebremst. Wenn die Paarzusammensetzung ungünstig ist, kann es der aktivere Partner als unnütz empfinden, dass jemand neben ihm sitzt, während sich der passivere schuldig fühlt.
• Manche Partner können unter Umständen nicht gut zusammen arbeiten, sei es wegen unterschiedlicher Arbeitstile, Denkweisen oder aus persönlichen Gründen.
• Zu Beginn ist eine weniger produktive Gewöhnungsphase notwendig.
• Es kann passieren, dass einer der Partner abgehängt wird und den Gedanken des anderen nicht mehr folgen kann, was dazu führt, dass er letztlich nutzlos und frustriert daneben sitzt.
• Die Arbeit mit Partnern, die die Körperpflege vernachlässigen, kann unangenehm sein.

Wirtschaftlichkeit

Es gibt verschiedene Versuche, die Wirksamkeit von Paarprogrammierung empirisch zu untersuchen. Mehrere Studien dazu werden in dem Buch "Making Software" von Andy Oram und Greg Wilson (Seite 311 ff.) zitiert. Große Übereinstimmung herrscht darin, dass paarweises Programmieren zu weniger Fehlern und besserem Software-Design führen. Welcher wirtschaftliche Vorteil sich letztlich ergibt, ist schwer zu ermitteln, da die Qualität von Software sich sehr langfristig in Form von Wartungskosten auswirkt und schwer zu berechnen ist.

Wenn ich bedenke, wie teuer es ist, Fehler zu beheben und Software nachträglich umzubauen, gehe ich davon aus, dass sich Paarprogrammierung lohnt. Softwareentwickler sind eben nicht in erster Linie Schreibkräfte, sondern Denker; und deshalb lohnt es sich auch, zwei Entwickler denken und nur einen davon schreiben zu lassen.

Praktische Tipps

Damit das Programmieren in Paaren funktioniert, sind ein paar Dinge zu berücksichtigen. Das fängt beim Arbeitsplatz an, der mit ein bis zwei großen Monitoren ausgestattet sein sollte. Der Tisch sollte vorne eine gerade Kante haben oder sie sollte nach außen gewölbt sein. Nach innen gewölbte Tische sind unpraktisch, weil die beiden Entwickler sonst entweder voneinander weg gucken oder sich in die Quere kommen würden. Überlegenswert ist auch, zwei Tastaturen und zwei Mäuse bereitzustellen, da der Besitz der Eingabegeräte wesentlichen Einfluss auf die Aktivität hat.

Bevor eine Aufgabe begonnen wird, ist es hilfreich, wenn beide Entwickler kurz besprechen oder auch skizzieren, wie die Aufgabe gelöst werden soll. Dadurch bekommen beide das gleiche Verständnis von der Aufgabe und Irrwege werden vermieden. Wenn während der Arbeit etwas unklar ist, sollte so lange gefragt werden, bis Klarheit herrscht und erst dann weitergemacht werden. Andernfalls besteht die Gefahr, dass ein Programmierer den Anschluss verliert und nur noch Zuschauer ist. Damit beide bei der Sache bleiben ist es zudem gut, wenn die Rollen "Fahrer" und "Beifahrer" regelmäßig gewechselt werden. Das abwechselnde Schreiben von Tests und Implementierung ist ebenfalls hilfreich.

Weitere Information

• Pair Programming, Chih-Song Kuo
• pair programming pros and cons, Nick Evans
• Pair Programming: Pros and Cons, Diskussion auf stackexchange.com
• Why Every Startup Should Pair Program – Wie Paarprogrammierung die Unternehmenskultur prägt.
• Successfully Adopting Pair Programming, Jay Fields
• Extreme Programming, Kent Beck, Addison Wesley 2003, Seite 100 ff.
• Making Software, Andy Oram und Greg Wilson, O'Reilly 2010, Seite 311 ff.