Beim Pair-Programming arbeiten immer zwei Personen gemeinsam am Quellcode. Dabei können beide in den Code eingreifen, optimalerweise mit zwei Mäusen und zwei Bildschirmen. Letztlich geht es aber weniger darum, wer nun welchen Teil des Codes tippt, sondern viel mehr darum, direkt zu zweit Ideen zu entwickeln und umzusetzen.

Pair-Programming eignet sich etwa, um einen Entwickler auf Junior- und einen auf Senior-Level zusammenzubringen, und so den neuen Kollegen ganz nebenbei einzulernen. Für besonders wichtige Projekte hingegen sind zwei Entwickler auf ähnlich hohem Niveau sinnvoller. Statt zwei reinen Entwicklern können aber auch ein Entwickler und beispielsweise ein Grafik– oder Usability-Designer zusammenarbeiten. Das führt am Ende zu einem besseren Code, der sauberer und fehlerfreier ist. Auch wenn die Zweierteams nicht auf die doppelte Geschwindigkeit kommen, sind sie insgesamt schneller als wenn sie alleine arbeiten würden.

Auf jeden Fall lässt sich natürlich die alte Weisheit nennen, dass vier Augen mehr sehen als zwei. So können Fehler direkt abgefangen werden. Außerdem ist das Rubber-Ducking zum Debuggen nicht umsonst weitverbreitet und zeigt bereits, dass es hilft, anderen seinen Code zu erklären. Da ist es vom besagten Quietsche-Entchen zu einem echten Menschen mit Programmierkenntnissen und der Möglichkeit zur Diskussion auch nicht mehr weit.

Da der aktuell Schreibende seinen Code immer erklären muss, korrigiert er ihn zwangsläufig schon beim Konzipieren und hat zusätzlich das Feedback der anderen Person, sodass Fehler oder auch nur nicht bedachte Grenzfälle schneller auffallen. Der am Ende entstandene Code ist dann im Optimalfall direkt eine Kombination von mindestens zwei Lösungsansätzen und entsprechend durchdachter als die Idee eines einzelnen Programmierers, der für sich arbeitet.

Durch das gemeinsame Arbeiten findet weiterhin eine stetige Evaluation statt, die mindestens zu sauberer Arbeit und lesbarerem Code führt. Wenn einer der zwei Partner aber gar kein Entwickler ist, sondern seinen Schwerpunkt bei Grafik oder Usability hat, werden auch diese Aspekte direkt mit angegangen. Das erspart im besten Fall ein Nacharbeiten.

In erster Linie hängt der Erfolg des Pair-Programmings von den Menschen ab, die zusammenarbeiten sollen. Das Team sollte auf keinen Fall ohne vorherige Tests zusammenarbeiten. Auch Teambildungsmaßnahmen im Vorfeld sind nicht verkehrt, ebenso wie eine Kommunikationschulung für beide. Wichtig ist auch, dass die beiden Personen keinen zu großen Wissensunterschied haben (außer genau das ist, wie oben angesprochen, gewollt), sodass ein Gespräch auf Augenhöhe möglich ist und sich keine Hierarchien bilden.

Aber trotzdem kann es zu Schwierigkeiten kommen. Die offensichtliche Möglichkeit ist die, dass die Partner nicht gut miteinander auskommen und die Kommunikation schwerfällt. Da unweigerlich auch Kritik geübt werden muss, kann eine solche Konstellation schnell zu Auseinandersetzungen führen und resultiert dann in deutlich geringerer Effizienz und zwei unzufriedenen Mitarbeitern.

Allerdings können sich die beiden Personen auch zu gut verstehen und sich dann gegenseitig ablenken. Wenn beide eigentlich lieber die gemeinsamen Hobbys diskutieren würden, lenken sie sich wahrscheinlich eher von der Arbeit ab, statt den anderen fokussiert zu halten. Auch das ist im Endeffekt eine schlechtere Performance und bringt eher selten die gewünschte Leistung.

Wenn sich aber zwei gefunden haben, die gut und konzentriert zusammenarbeiten können, ist die Arbeit vergleichsweise anstrengender, da sie eben fokussierter ist. Das bedeutet, dass hier besonders auf Pausen und Ausgleich geachtet werden muss.

Pair-Programming ist also ein durchaus spannendes Konzept, dessen Erfolg am Ende davon abhängt, wie gut das Team miteinander arbeitet. Dann kann zu zweit mehr erreicht werden als alleine. Allerdings sollte die Entscheidung dafür nicht leichtfertig getroffen werden, so schön die Vorteile auch sind.

Das könnte dich auch interessieren:

• Hinter den Kulissen bei VW: Wie gut funktioniert Pair-Programming?
• Mob-Programming: Was ein Entwickler in fünf Monaten gelernt hat