1 + 1 = 3

Hallo Spaß-Coder.

Heute wollen wir uns mit dem Thema Pair Programming beschäftigen. Wir werden zum einen die Frage beantworten, warum es uns so viel Spaß macht und zum anderen ausführen, warum es auch aus wirtschaftlicher Sicht sinnvoll ist, wenn man es mittel- bis langfristig betrachtet.

 

Zunächst aber mal wieder ein paar Bilder zur Einstimmung. Woran denkt ihr, wenn ihr folgendes Bild seht – bezogen auf Softwareentwicklung und der Anforderung eine Änderung durchzuführen:

Wir haben eine saubere, asphaltierte Straße –> sauberen, gut strukturierten Code. Wir werden gut geführt durch Leitplanken und der Linie in der Mitte der Straße. Sicher, es ist eine kurvige Straße, aber wir fühlen uns recht sicher, diese ohne größere Probleme meistern zu können.

Mit welcher Art von Fahrzeug glaubt ihr, kommen wir hier schnell vorwärts?

Wie wäre es mit diesem hier?

Wir haben glatte Straßen, können den Weg gut erkennen und müssen uns nicht groß anstrengen. Hier kommen wir sehr gut und schnell alleine und mit einem Fahrzeug aus, dass für diese Art der Straße optimiert ist.

 

In der Realität finden wir Code dieser Art leider viel zu selten. Die Herausforderung, die wir uns bei einer neuen Anforderung an unserem Code stellen müssen, haben eher den Charakter des folgenden Bilds:

Ein Weg lässt sich erahnen, dieser ist aber schmal und steinig. Es geht bergauf und bergab. Nur einen Meter zu weit zur Seite abgewichen und schon werden wir abstürzen. Haben wir nun kein Sicherungsseil (nennen wir es mal „automatisierte Tests“), wird dies mit Sicherheit keinen guten Ausgang finden.

Wie weit kommen wir hier mit unserem oben abgebildeten Fahrzeug? Genau, nicht sehr weit. Das liegt zum einen natürlich an der geringen Bodenfreiheit, die uns auf dem unwegsamen Gelände eher hinderlich ist. Was aber würde uns hier helfen?

Ihr habt sicher schon erraten, dass dies kommen wird. Aber warum? Was genau unterscheidet das Fahren eines Rall-Autos vom Fahren eines Formel 1 Boliden? Sicherlich fallen die offensichtlichen Unterschiede auf: die höhere Bodenfreiheit, das Reifenprofil, die Windschutzscheibe, die vor dem aufspritzenden Schlamm schützt. Aber schauen wir mal genauer hin:

Ein Blick ins Cockpit zeigt uns, dass hier nicht nur ein Fahrer im Wagen sitzt und ihn über das schwere Terrain steuert, sondern zwei. Der eine fährt das Auto und hält es auf Kurs. Dabei konzentriert er sich auf die Strecke, die er unmittelbar vor Augen hat. Der andere sitzt daneben und schaut auf eine Karte. Er gibt dem Fahrer Anweisungen dazu, was als nächstes auf ihn zukommt, damit dieser sich darauf vorbereiten kann.

 

Was ist Pair Programming?

Auch beim Pair Programming sitzen wir zu zweit vor dem Rechner, in der Regel um ein Feature zu entwickeln. Einer der Partner sitzt dabei an der Tastatur und schreibt, der andere sitzt daneben und schaut zu. Die Rollen entsprechen dabei genau den gleichen, wie beim Fahren eines Rally-Autos. Man nennt die beiden Rollen:

Driver und Navigator

Der Driver ist derjenige, der an der Tastatur sitzt und den Code schreibt. Er hält den gerade zu entwickelnden Code im Auge und konzentriert sich darauf, den nächsten Schritt umzusetzen. Der Navigator kann sich derweil schon mit dem nächsten Schritt beschäftigen oder den aktuellen Schritt noch einmal hinterfragen und auf Sinnhaftigkeit überprüfen.

Beim Pair Programming ist es aber noch wichtig, dass die beiden Rollen regelmäßig wechseln. Was sich beim Rallyfahren eher schlecht umsetzen lässt, ist beim Pair Programming eines der wichtigsten Regeln. Durch das Wechseln der Rollen hat jeder mal einen anderen Blick auf den Code und beschäftigt sich gedanklich auf anderen Ebenen. Das verbessert das Gesamtverständnis für den Code und das umzusetzende Feature. Auch erhöht sich durch den Wechsel der Grad des Wissensaustauschs.

 

Warum Pair Programming?

Die Aufgaben teilen sich also auf in kurzfristige und mittelfristige Umsetzung. Ihr kennt das sicher, dass ihr, wenn ihr alleine Code schreibt am Ende eines logischen Blocks ankommt und euch fragt, ob das nun wirklich der richtige oder beste Weg der Implementierung war. Falls nicht, fangt ihr in diesem Fall noch einmal von vorne an. Ein Navigator hätte euch darauf bereits vorher hinweisen können und somit Zeit und Mühe gespart. Sind wir alleine unterwegs, können wir uns entweder auf die kurzfristige, oder auf die mittelfristige Lösung konzentrieren. Beides gleichzeitig ist nicht in gleicher Qualität möglich.

Es gibt aber noch weitere Gründe, die dafür sprechen, Code nicht alleine, sondern in einem Pärchen zu entwickeln:

Weniger Fehler
Pair Programming führt zu weniger Fehlern und somit zu weniger Aufwand bei der Fehleranalyse und Suche. Je früher ein Fehler im Entwicklungsprozess gefunden wird, desto günstiger ist die Behebung. Ein guter Navigator, der einen Fehler bereits bei der Beobachtung des Drivers entdeckt sorgt also für die günstigste aller möglichen Fehlerbehebungen.

Höhere Disziplin
Paare entwickeln viel eher an der richtigen Stelle und machen kürzere Pausen. Arbeiten wir in Paaren zusammen, lassen wir uns weniger ablenken, etwa durch E-Mails oder Kollegen. Auch ist die Hemmschwelle anderer Kollegen höher, ein Paar zu stören, als einen einzelnen Entwickler.

Besserer Code
Beim Pair Programming entwickelt man sich weniger leicht in Sackgassen und erreicht so eine höhere Qualität. Auch werden Konventionen meist sofort eingehalten und bessere Namen gefunden. Auch die Struktur des Codes ist meist leichter verständlich und nachvollziehbarer als bei einem einzelnen Entwickler.

Freude an der Arbeit
Pair Programming macht Spaß! Es ist oft spannender und interessanter als alleine zu arbeiten. Auch hilft es dabei, den einzelnen vor Überforderungen zu schützen. Wenn einer nicht weiter weiß, hat der andere vielleicht eine Idee. Haben beide keine, lässt sich zu zweit schneller ein möglicher Lösungsansatz entwickeln als allein. Auch ist die Hemmschwelle geringer nach Hilfe zu fragen. Man hat sich ja bereits eingestanden, dass man feststeckt, was meist der Hauptgrund dafür ist nicht nach Hilfe zu fragen, der eigene Stolz.

Wissensvermittlung
Jeder hat Wissen, das andere nicht haben. Pair Programming ist eine Möglichkeit, dieses Wissen zu teilen. Wenn das gesamte Team Pair Programming betreibt 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. Es verringert somit den Bus-Faktor.

Teambildung
Durch Pair Programming lernen sich Entwickler gegenseitig schneller kennen. Auch steigt der gegenseitige Respekt, wodurch die Zusammenarbeit verbessert werden kann.

Was spricht gegen Pair Programming?

Kosten
Pair Programming führt zu einer geringeren Geschwindigkeit bei der Programmierung. Das ist naheliegend, da ja nun nicht mehr nur einer, sondern zwei Entwickler mit dem gleichen Feature beschäftigt sind. Aber wie hoch glaubt ihr, ist der Aufwand eines gut funktionierenden Paars? Doppelt so hoch, weil es zwei Entwickler sind? 150%, weil sie eher die richtige Lösung finden? 100%, weil sie nun doppelt so schnell sind, da sie nicht mehr abgelenkt werden?

Üblicherweise geht man davon aus, dass ein Paar für ein Feature etwa 115% der Zeit braucht, also pro Entwickler etwa eine um 7,5% geringere Produktivität gegenüber einem einzelnen Programmierer hat. Da die Vorteile wie etwa bessere Qualität und ordentlicher und lesbarer Code bereits während der Entwicklung zum Tragen kommen, werden die Kosten hierbei sogar noch geringer ausfallen (was aber nur schwer messbar ist). Schauen wir uns die langfristigen Vorteile wie etwa den Wissensaustausch oder die weichen Faktoren, wie Spaß an der Arbeit an, sind die Kosten sicherlich gut investiert.

Teamfindung
Pair Programming ist zu Beginn – je nach eigener Persönlichkeit – ggf. ein wenig schwierig. Seid ihr der Driver, schaut euch nun ständig jemand über die Schulter und sagt euch, was ihr „falsch“ macht. Seid ihr der Navigator, müsst ihr euch darauf konzentrieren, den Code des Drivers zu lesen, zu verstehen und in den Kontext des Features zu bringen. Passt der Code zu dem was ihr im Team erreichen wollt? Sind die Namen gut gewählt? Ist der Code ordentlich strukturiert? Falls nicht, müsst ihr es ansprechen.

Diese Offenheit für Feedback – geben und nehmen – ist nicht jedem gegeben und muss geübt werden. Das kostet neben Überwindung auch Zeit und Kraft. Auch eignen sich nicht alle Paare für Pair Programming. Kommt ihr mit einem Partner auch nach mehrmaligem Versuchen und der Kenntnis der Regeln zu der Erkenntnis, dass ihr nicht gut zusammen arbeiten könnt, muss auch dies offen angesprochen werden.

Unterschiedliche Programmierstile
Wichtig für gut funktionierendes Pair Programming ist ein einheitlicher Programmierstil. Es ist hilfreich sich im Team auf ein paar grundlegende Regeln zu einigen. Wo stehen Variablendeklarationen? Wie sollen Klassen benannt werden? Wie formatieren wir den Code? Es ist wenig hilfreich, sich im Pair über solche Themen zu unterhalten, das hält auf und verringert die Produktivität. Wurde sich einmal auf eine Konvention geeinigt, sorgen beide dafür, dass sie eingehalten werden.

Urheberrecht und Haftung
Wer hat das Recht am Code, wenn er nicht nur von einem geschrieben wird? Wer haftet für fehlerhaften oder urheberrechtsverletzenden Code? Entwickelt ihr Code im Paar für euer Unternehmen, stellen sich diese Fragen sicher nicht, in beiden Fällen tritt das Unternehmen ein. Aber was ist mit Code, der unternehmensübergreifend  erstellt wird? Oder Code, den ihr privat im Paar entwickelt? Diese Fragen lassen sich deutlich schwerer beantworten, als wenn der Code nur von einem Entwickler geschrieben wurde.

 

Wie kann man Pair Programming durchführen?

Im Grunde ist es recht einfach. Setzt euch zu zweit vor den Rechner. Einer an der Tastatur (der Driver) und einer daneben (der Navigator). Sorgt dafür, dass beide einen guten Blick auf den Bildschirm haben (bei zwei Monitoren bietet es sich ggf. an, den Bildschirm zu spiegeln). Besprecht, auf welchem Weg ihr die Problemstellung angehen wollt und sagt immer, was ihr als nächstes zu tun gedenkt. Der Navigator unterbreitet dauernd Vorschläge zur Verbesserung des Codes und überlegt sich das weitere Vorgehen. Der Driver konzentriert sich auf die effektive Umsetzung der Ideen in Code.

Wechselt regelmäßig die Rollen um den Blickwinkel auf die Problemstellung zu ändern. Auch ist es hilfreich, bei bestimmten Themenschwerpunkten zu wechseln, je nachdem, wie gut der jeweils andere ist und ob der Fokus auf schnellen Erfolgen oder dem Austausch von Wissen liegt.

Haltet euch nicht mit Feedback zurück, tauscht euch über alle Aspekte aus, jeder von euch kann vom anderen lernen! Es beginnt bei der Bedienung der IDE über bestimmte Coding Patterns bis hin zur Entwicklung von ausgefeilten Algorithmen. Seid offen für Neues und fühlt euch nicht auf den Schlips getreten, wenn ihr einen Verbesserungsvorschlag erhaltet.

Beim Pair Programming kann man ausgehend vom Wissensstand der Partner von folgenden Zusammenstellungen ausgehen:

Experte – Experte

Dies ist offensichtlich die beste Kombination im Hinblick auf das zu erwartende Ergebnis und die Entwicklungsgeschwindigkeit. Liegt der Schwerpunkt der beiden Experten allerdings zu nah beieinander, besteht die Gefahr, dass die Lösung sich auf diesen Schwerpunktbereich konzentriert. Frei nach dem Indonesischen Sprichwort Wer nur einen Hammer hat, für den sieht jedes Problem wie ein Nagel aus. Offenheit und konstruktiver Problemumgang hilft hier aber auch den Experten, kreative Lösungen zu finden.

Experte – Anfänger

Bei dieser Kombination spricht man auch oft vom Coaching. Der Experte gibt sein Wissen an den Anfänger weiter. Dabei muss der Anfänger kein kompletter Neuling auf dem Gebiet der Programmierung sein. Vielleicht ist er nur neu im Projekt oder kennt die Programmiersprache oder Entwicklungsumgebung noch nicht. Damit der Lerneffekt hoch ist, bietet es sich an, wenn der Anfänger die Rolle des Drivers übernimmt. Aufgabe, die ich selbst erledige, bleiben besser haften, als wenn ich nur zuschaue.

Anfänger – Anfänger

Was auf den ersten Blick wie eine sinnlose Kombination klingt, entpuppt sich auf den zweiten Blick als Chance. Es gibt ein Thema, mit dem sich im Unternehmen noch niemand beschäftigt hat, was aber die Zukunft des Markts ist? Nun könnt ihr euch einen Experten von außen holen (was bei bewährten Umfeldern sicherlich keine schlechte Idee ist), oder ihr setzt euch zu zweit hin und tüftelt gemeinsam an einer Lösung. Dabei ist dies effizienter, als wenn sich einer allein durch das Thema wühlen muss (siehe oben, Überforderung).

 

Wichtig zu verstehen ist dabei, dass diese Kombinationen sich regelmäßig ändern können. Teilweise sogar in einer einzigen Session! Einer der Partner hat noch nie was mit Lambda-Expressions gemacht, der andere schon? Experte – Anfänger. Keiner der beiden kennt sich mit Linq aus? Anfänger – Anfänger. Beide wissen, wie sie ein Singleton Pattern implementieren? Experte – Experte. In jedem von uns steckt ein Experte – und ein Anfänger. Wenn wir uns das bewusst machen, ist der Umgang damit im Paar deutlich einfacher.

 

Unsere Erfahrung mit Pair Programming

Wir arbeiten mittlerweile seit mehr als 10 Jahren im privaten Umfeld fast ausschließlich im Pair Programming. Zunächst war es aus der Not heraus geboren. Als wir mit unseren ersten Projekten anfingen hatten wir beide jeweils einen PC, keinen Laptop und von schnellem Internet für eine Online-Zusammenarbeit waren wir noch Jahre entfernt (erinnert ihr euch noch an 56k-Modems? Seht ihr…)

Später kamen dann Zweit-PCs und Laptops hinzu, aber wir haben trotzdem weiterhin im Paar gearbeitet. Wir haben viel voneinander gelernt und das gemeinsame Entwickeln macht uns soviel Spaß, dass wir einen Abend in der Woche und ab und zu am Wochenende genau das tun: im Paar Programmieren. Wir haben gemeinsam Aha-Erlebnisse, motivieren uns gegenseitig (was allerdings auch nicht immer funktioniert ;-)) und feiern kleine gemeinsame Erfolge.

Wir sind davon überzeugt, das Pair Programming die beste Art ist, Code zu schreiben.

Wir wünschen euch viel Spaß beim Ausprobieren.

Eure Spaß-Coder

P.S.: Hier noch eine (englischsprachige) Videoempfehlung zum Thema Pair Programming von der North Carolina State University

 

Dieser Artikel basiert neben unseren Erfahrungen auf folgenden Quellen:

Alistair Cockburn, Laurie Williams: The Costs and Benefits of Pair Programming

http://de.wikipedia.org/wiki/Paarprogrammierung

http://en.wikipedia.org/wiki/Pair_programming

 

Verwendete Bilder:

British Grand Prix 2014, Formula 1 Practice Session 1: https://www.flickr.com/photos/scottkil/14584934685/
Liqui Molly Rally 2: http://www.freeimages.com/photo/58379
Plain Road: http://www.freeimages.com/photo/1090380
Rocky Road: https://www.flickr.com/photos/oneeighteen/14429945028/