Stand: 2012-09-29

Pro und kontra Paarprogrammierung

Lohnt sich das paarweise Programmieren? Was spricht für und gegen die Programmierung zu zweit?

Inhalt

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

Kontra

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