Pair Programming Tipps und Studien

Pair Programming ist sehr gut für das eigene Team und die Software-Qualität. Leider gibt es viele Vorbehalte gegenüber dieser tollen Art zu arbeiten. Das ist sehr schade. Seit einigen Jahren bin ich ja auf Konferenzen und User-Groups mit der Funk-Tastatur unterwegs und habe ja auch bei den Never Code Alone Events #ncaevents ausschließlich Pair-Programming im Fokus. Hier gebe ich euch ein paar gute Tipps für den reibungslosen Ablauf.

Driver Navigator / Fuck it

Pair Programming Wikipedia

Sucht man in staubigen Sachbüchern oder bei Wikipedia nach Pair-Programming so kommt man ganz schnell zum Driver-Navigator-Spiel. Hier soll die Person – ganz Gender neutral 😉 – an der Tastatur nur tippen und der Navigator praktisch die Richtung vorgeben. Das mag ja pädagogisch wertvoll sein, aber wer steht schon auf Pädagogik. Schnappt euch bitte jeder eine Tastatur und arbeitet gemeinsam und zusammen. Alles andere führt nur zu völlig unnötigen Frust. Pair Programming ist kein Selbtsläufer und muß auch geübt werden. Dabei ist auch viel Geduld und natürlich Respekt gefragt. Es geht nicht um richtig und falsch, sondern um eine gemeinsame Sprache und Lösung.

Bekannte Pitfails die ihr vermeiden solltet

• Beide Webdeveloper müssen sich mit dem aktuellen task auskennen, damit es nach vorne geht. Sonst ist es nur ein Know-How Transfer. Der ist zwar auch wichtig, aber so dann doch sehr ineffizient und kostenintensiv
• Pair-Programming ist kostenintensiv. Deshalb zieht in der Zeit dran und gebt Gas. Ihr werdet so oder so nicht den doppelten Output haben. Aber natürlich ist das Ergebnis klarer und weniger Bug anfällig. Bleibt aber nicht in Schönheit oder Prinzipien und Diskussionen hängen. Liefert gute Arbeit ab.
• Redet miteinander. Natürlich auch der Driver. Tauscht euch aus, plat gemeinsam den nächsten kleinen Schritt und setzt ihn gemeinsam um. Das muß auch gelernt werden. Macht die Schritte nicht zu groß und wechselt auch häufig ab.
• Pair-Programming klappt nur mit Leuten, die sich grün miteinander sind und im wahrsten Sinne des auch riechen können. Leider gibt es hier immer wieder vielleicht unangenehme Situationen. Tut auch selbst einen gefallen und geht da mit frischen Klamotten hin und Zähneputzen und Kaugummi ist auch ok. Macht gerne auch mal das Fenster auf 😉

Quellen zu Pair-Programming

In der Software-Entwicklung ist Pair-Programming kein neues Topic. Allerdings ist es gerade im Bereich Webdeveloping viele Jahre verloren gegangen. Neben Uncle Bob Martin Fowler und dem Xtreme-Programming gibt es natürlich noch zahllose andere Namen. Fred Brooks, John Von Neummann, Richard Gabriel, Jerry Weinberg or Edsger Dijkstra sollen hier mal nur einige sein. Und natürlich findet das Thema in der Agilen Transformation auch eine immer größere Aufmerksamkeit.

• 1992 – Das dynamische Duo – Larry Constantine Berichtet über Pair Programming bei der Whitesmith Inc. Hier haben schon damals 2 Programmierer mit einer Tastatur gemeinsam gearbeitet. Man sprach in diesem Zusammenhang von einem Schulterblick.
• 1993 – Die Studie “The benefits of collaboration for student programmers” von Wilson befasst sich schon früh mit den Vorteilen von Pair-Programming. Allerdings ging es mehr um den Nachweis, daß es überhaupt funktioniert.
• 1995 – In dem Buch “Pattern Languages of Program Design” gibt es ein Kapitel von Jim Coplien „A Generative Development-Process Pattern Language“. Es befasst sich ebenfalls mit Pair-Programming.
• 1998 – Einer der ersten Artikel zum Thema Extreme Programming taucht auf. In “Chrysler goes to Extremes” wird Pair Programming als eine der wichtigsten Methoden vom C3 team hervorgehoben. Kurze Zeit später wird Pair-Programming zu einer der 12 XP Methoden.
• 2000 – Die Regeln für das Pair-Programming als Driver und Navigator werden festgehalten und als Einstieg in Pair-Programming empfohlen. Hierzu gab es ein Mailing-List-Posting. Wie schon erwähnt sind diese Regeln in der Praxis nur bedingt anwendbar. Hilfreich ist an dieser Stelle auch ein Artikel von Sallyann Bryant „Pair programming and the mysterious role of the navigator„.
• 2002 – Laurie Williams und Robert Kessler verfassen ihr erstes Buch mit dem Titel “Pair Programming Illuminated”. Es beinhaltet zahlreiche praktische Beispiele und schöne Diskussionen zu dem Thema.
• 2003 – ein anonymer Artikel im C2 Wiki mit dem Titel Ping-Pong-Pair-programming taucht auf. Er verbindet Pair-Programming mit Test-Driven-Development. Die Software-Kammer hat hier auch öfters Veranstaltungen zu dem Thema.

Webdeveloper Skills

Wie anfangs erwähnt ist es wichtig vom Know-How her gleiche Leute in einem für beide Beteiligten aktuellen Thema zusammen zu setzen. Gerade, wenn man mit Test-Driven-Development in der Ping-Pong-Variante arbeiten möchte ist es wichtig hier nicht zu weit auseinander zu sein. Sollten die Skills aber weiter auseinander sein, oder man auch in größeren Gruppen gemeinsam coden, dann kann man hier auch ein wenig die Rollen gezielt verteilen.

• Anfänger
  • Für besseres Selbstvertrauen und einen guten Lerneffekt bietet sich hier die Rolle als Driver an.
  • Als Driver soll er aber ruhig Fragen stellen dürfen und weiter gebracht werden
• Fortgeschrittener
  • Kann jederzeit die Tastatur übernehmen und seine eigene Rolle einfach tauschen.
• Profi
  • Kann die Moderation übernehmen und das ganze Pair-Programming in seiner Session führen. Damit wird das Ziel nicht verloren und sich nicht in Details verloren.

Voraussetzungen Pair-Programming

• Ein separater heller und abgegrenzter Raum in dem man ungestört bei geschlossener Türe arbeiten kann
• Ein großer Monitor. Zu zweit an einem Rechner ist es zu klein. Beamer müssen hochauflösend und gut lesbar sein.
• Die IDEs sollten mit hellen Themes betrieben werden. Das sieht man deutlich besser und ist wesentlich lesbarer.

Erwartete Resultate

• Verbesserte Code-Qualität durch höhere Lesbarkeit
• Know-How Transfer unter den Mitarbeitern und schnellere Einarbeitung und effektivere Arbeitsweise im gesamten Projekt
• Webdeveloper können sich besser gegenseitig vertreten und Tasks übernehmen im Falle von Krankheit, Urlaub etc.
• Erhöhte Skills und Motivation durch eine verbesserte gemeinsame Arbeitsweise und dem hohen Know-How Transfer in beide Richtungen
• Effektivere Absprachen und kürzere Informationswege unter den Webdevelopern
• Weniger Unterbrechungen von Entwicklungsprozessen, da man zu zweit natürlich weniger nebenher macht

Potentielle Kosten

Ein reiner Blick auf die Kosten darf beim Pair-Programming leider nicht die entscheidende Rolle spielen. Man geht insgesamt von 15% Mehrkosten aus. Allerdings ist das ein reiner Blickwinkel auf die Abarbeitung von Tickets. Und dafür ist der Wert ja weit von 200% entfernt. Weniger Bugs, eine höhere Motivation der Mitarbeiter und eine viel höhere Zuverlässigkeit ist sicherlich viel mehr wert.

Akademische Publikationen

• Leider sehr theoretisch
• How Pair Programming Really Works eine Zusammenfassung des Driver-Navigator-Prinzips
• Empirical
• The Collaborative Software Process, Laurie Williams Doktor Arbeit, mit dem Fokus auf der Steigerung der Qualität gegenüber entstehenden Kosten
• The effectiveness of pair programming: A meta-analysis,
  beinhaltet 18 Studien über die Steigerung der Code-Qualität und die effektivere Entwicklung bei einfacheren Tasks. Hier wird ebenfalls die rasche und gute Entwicklung von Juniror Webdevelopern betrachtet.