nach \cite{Haase2006}

• Ziele: Global Code Ownership, Mentoring/Training, höhere Codequalität
• Regeln/Voraussetzungen
  • die Teilnehmer sollten das Keyboard alle 10-15 Minuten austauschen
  • die Sessions sollten nicht zu lange dauern (max. 3-4 Stunden)
  • beide Partner sollten ungefähr auf dem gleichen Wissensstand/Skilllevel sein
    

    * jeder Partner bekommt eine "rote Karte", die er ziehen kann, wenn er meint, dass gerade etwas passiert, das fachlich oder persönlich nicht tragbar ist ([[http://igloocoder.com/archive/2007/05/18/1215.aspx|IglooCoder]])

    * Möglichkeit/Gelegenheit, Pair Programming "einzuführen": bei auftretenden Bugs in vorhandenem Code, den Kollegen, der diesen Code geschrieben hat, bitten, mit ihm gemeinsam den Bug zu fixen. So verteilt sich Code Ownership auf beide Kollegen.
    

nach \cite[S. 319]{Goodliffe2006}

• Wissenstransfer zwischen Entwicklern
• zentriert den Fokus auf das Entwickeln (und vermeidet Tagträume)
• erhöht die Disziplin
• vermindert die Unterbrechungshäufigkeit (man stört zwei Personen, die arbeiten nicht so gerne, wie eine einzelne)
• quasi "Echtzeit-Reviews" → besserer Code als Ergebnis
• sozialer Faktor: die Entwickler lernen sich besser kennen und das fördert die Moral
• Collective Code Ownership
• verteilt gute Codepraktiken und -standards unter den Entwicklern
• unterstreicht den Entwicklungsprozess

nach \cite[45:00]{Haines2009}

• kontinuierliches Code-Review
• man muss zwei Leute überzeugen, wenn man Schrott programmieren will
• langweilige Aufgaben werden interessanter
• schwierige Aufgaben werden leichter
• weniger Fehler im Code
• Code kann schneller in Produktion gehen
• saubererer Code
• zwei Leute "kennen" den Code → Truck Factor

nach \cite{Wray2009}

• Pair Programming Chat: Durch den verbalen (!) Austausch zwischen den beiden Entwicklern wird den Sprechenden das Problem noch einmal deutlich und Studien haben gezeigt, dass dies hilft, Fehler zu sehen oder Probleme schneller zu lösen. Außerdem regen die Fragen, die der Partner stellt, dazu an sich intensiver mit der Materie auseinanderzusetzen.
• Pair Programmers Notice More Details: Menschen erkennen schlecht Änderungen, die um sie herum stattfinden, wenn sie nicht explizit darauf achten (Beispiel: Gorilla-Experiment). Zwei Entwickler achten vielleicht auf unterschiedliche Dinge und unterstützen sich somit gegenseitig. Auf lange Sicht gleichen sich die Entwickler aber an (pair fatigue), sodass man öfter einmal die Partner tauschen sollte.
• Fighting Poor Practices: Der Partner zwingt den Entwickler dazu, sauberer zu programmieren, da er immer unter Beobachtung steht und nicht "mal eben schnell" unsauberen Code schreiben kann.
• Sharing And Judging Expertise: Entwickler sind unterschiedlich produktiv (gute können z.B. bis zu 10x so produktiv arbeiten wie schlechte). Leider erkennen die schlechten Entwickler oft nicht, dass sie schlecht sind, bis sie mit einem besseren Entwickler zusammenarbeiten. Das Level an Erfahrung gleicht sich beim Pair Programming auf lange Sicht an und es dient daher quais als Schulungsmaßnahme für die Entwickler.

nach \cite[50:00]{Haines2009}

• "Das Management will kein Pair Programming!" → Das ist keine Ausrede! Wir als Entwickler sind verantwortlich für guten Code und müssen/dürfen entscheiden, wie dieser erstellt wird. Wir schreiben den Managern auch nicht vor, wie sie ihre Diagramme zeichnen sollen. Wer PP will, wird einen Weg finden, z.B. zwei Wochen lang ausprobieren und Management die Ergebnisse in Zahlen vorlegen, oder einfach den Job wechseln.