How to facilitate a conversation between people, where the byproduct is code?

[caichinger]

Bezugnehmend auf #99

Pair Programming sollten wir etwas anders verkaufen als das klassische und fixed "driver / navigator" - Bei Zühlke wurde ich von Steve Freeman informiert, dass das eine veraltete Ansicht ist und eigentlich nicht richtig ist. (Edit: Zugehöriges paper: http://oro.open.ac.uk/28909/1/XP2011PlonkaSegalSharpVanderLinden.pdf )

However, these role descriptions have been challenged by the results of recent studies [6, 7, 9] that show that driver and navigator do not think or act on different levels of abstraction.
[...]
They suggest defining the roles of driver and navigator by “the additional physical and cognitive load of typing borne by the driver” rather than “by segmenting the problem space according to level of abstraction”.

[dertseha]

Ich kann mich nichtmehr erinnern, von welcher dieser Seiten & Papers ich das mitgenommen habe, die Beschreibung gefällt mir am Besten:
"Pair (or group-) programming is a conversation between people, where the byproduct is code."

Als Vergleich: Bei einer "pen & paper" Übung wird ja auch weniger Wert darauf gelegt, dass "Ihr ein Blatt Papier mit Eurer Lösung füllen müsst." Sondern vielmehr: Sammelt gemeinsam Ideen und Zugänge, wie das Problem gelöst wird. Und anstelle eines Papiers, könnt Ihr jetzt eine IDE dazu nehmen um Eure Gedanken festzuhalten.

Bevor das zu sehr nach "Die beste Art einen Krieg zu gewinnen ist, nicht zu kämpfen" (oder so ähnlich) klingt: Anstelle den Leuten die Hüte aufzuzwängen "Du darfst nur im Großen denken, ignoriere Tippfehler" und "Du darfst nur Variablen benennen, ignoriere ob das Gesamtkonzept passt," kann ich so die Leute auf gleiche von Beginn an Ebene stellen - und der Unterschied ist grad mal, wer grad das Keyboard hat.
Die einzige "Anforderung", die ich habe ist "Seid Euch beide einstimmig, was getippt wird."

Da fällt dann auch alles darunter von "Ich möchte Dir was zeigen/erklären" über "Probieren wir das aus" bis hin zu "OK, ich glaub wir haben es, tippen wir es."

Es kann immer noch ein "constraint" sein, dass die Person mit Keyboard nur Namen vergeben darf, und die ohne nur "groß" denken darf - doch zielt das auf was anderes ab als "pair programming zu üben/erklären".

Dabei fällt mir ein, bei dem einen coderetreat wo group-programming geübt wurde, wurden auch die Regeln schrittweise gelöst. Zu Beginn musste eine Person nur tippen, eine durfte ansagen, der Rest nur zusehen. Die Regeln in den einzelnen Runden gelöst, war die letzte Runde "alle dürfen gleichbereichtigt Ideen kommunizieren und besprechen, nach Einstimmigkeit schreibt dann eine Person das am Keyboard."
Jetzt kann es sein, dass das auch eine "maturity-progression" ist - doch sehe ich das pair-programming in diesem Aspekt nicht anders, als der Endausbau in einer Gruppe.

Um auf die originale Frage zurückzukommen: Anstelle pair-programming als fixes "small-scale / large-scale" Rollengespann zu verkaufen, kann diese Formation als Beginner-Übung gemacht werden, nur mit dem bewussten Hinweis, dass das noch besser geht.

[caichinger]

Danke für's Teilen. Habe jetzt glaube ich besser verstanden, worum es dir geht. :)

Vielleicht machen wir beim nächsten CR eine Session in der wir versuchen, diese Überlegungen auf ein, zwei Folien abzubilden?

---

Findest du, dass wir Leuten Hüte aufzwängen oder fixe Rollengespanne verkaufen?
Bzw. findest du, dass das passiert?

Ich bin bei dir, gleichzeitig glaube ich, dass es gar nicht so einfach ist, Leuten Hüte aufzuzwängen - daher die Frage. :)

Vielleicht bin ich auch naiv und kenne einfach kein "strenges" Pair Programming.

---

"Pair (or group-) programming is a conversation between people, where the byproduct is code."

Finde ich schön. :)

Im diesem Bild ("Pair Programming = Konversation") ist für mich

• Driver schreibt das Protokoll
• Navigator moderiert den Prozess

und beide gestalten den Inhalt.

Die einzige "Anforderung", die ich habe ist "Seid Euch beide einstimmig, was getippt wird."

Das ist eh schon stark. :D

---

Für mich geht es um die Fragen

1. Was ist Pair Programming?
2. Warum mache ich Pair Programming?
3. Wie mache ich Pair Programming?

Glaube mit 3 kann man sich 1 und 2 annähern.

3 ist a priori sehr unklar und es braucht eine konkrete Minimalidee (Handlungsanweisung), damit man in's Tun kommt und sich mit Pair Programming praktisch auseinander setzen kann.

Das heißt die eigentliche Frage ist "Wie kann man gleichzeitig/gemeinsam an einer Code Base arbeiten?". Dafür brauchen wir einen Modus.

Für mich ist die "fixe Rollegespann"-Idee nicht viel mehr als:

• Wir arbeiten zu zweit (Warum? Einfach so?).
• Wir wollen Code schreiben, d.h. irgendwer muss sich um's Tippen kümmern (=Driver).
• Was tippen wir? Was macht die andere Person? Die andere Person leitet an (=Navigator).
• Außerdem wechseln wir uns ab (Warum? Einfach so?).

Daher finde ich das "fixe Rollengespann" okay, weil es einen konkreten Vorschlag macht.

Dann kann der Rest passieren.

mit dem bewussten Hinweis, dass das noch besser geht

Finde ich gut. Vielleicht ist das dann auch ein passender Anküpfungspunkt für Retro und die Frage, "Wie können wir das besser machen?".

[ReaSu]

Erlebnisbericht, nur knapp am Thema vorbei, weil Ensemble statt Pair:

Ich hab kürzlich mit einer Gruppe gearbeitet, die mit der Technik von Pair/Ensemble Programming nicht sehr vertraut war. Es hat sich sehr schnell dahin entwickelt, dass sich die Leute dann am meisten eingebracht haben, wenn sie Typist waren. (Ich finde genau drum schon die Begriffe Driver und Navigator problematisch. Obwohl ich weiß, woher das kommt, ist es noch immer unintuitiv, dass der Driver nicht der ist, der das ganze antreibt. Damit bin ich beileibe nicht allein.)

Ich hab überlegt, ob ich intervenieren soll, weil sie es ja "falsch" machen - hab mich dann dagegen entschieden. Weil die Rollen ja nur ein Mittel zum Zweck sind, aber nicht behindern sollen. Ich fand es wichtiger, dass wir gemeinsam gearbeitet haben, nicht eine Person alles dominiert, aber auch niemand links liegen gelassen wird, als dass wir uns an strenge Rollen halten.

Ich seh durchaus den Nutzen der klar verteilte Rollen: Wenn man sich nicht jedes Mal, wenn man mit jemandem arbeitet, über den Modus unterhalten muss, kann man schneller anfangen. Man kann sich schneller mit dem eigentlich Wichtigen beschäftigen - dem Code. Die Rollen können in diesem Fall die mental load reduzieren.

Andererseits seh ich die Rollen nur als ein Mittel zum Zweck. Dieser Zweck kann auch durch andere Mittel erreicht werden. Wenn man sich auf die Rollen versteift, kann es leicht passieren, dass diese plötzlich zum Mittelpunkt werden, und man sich mehr darauf konzentrieren muss, wer jetzt wann was sagen darf - meistens ist das nicht gewollt.

[caichinger]

Erlebnisbericht, nur knapp am Thema vorbei, weil Ensemble statt Pair:

Finde ich gar nicht am Thema vorbei. Hier passt alles rein rund um

"How to facilitate a conversation between people, where the byproduct is code?" ;)

Danke für's Teilen.

(In einem Experiment wäre es interessant gewesen, herauszufinden, ob die Gruppe produktiver ist, wenn "Typist" nicht alles machen muss.)

---

Typist

Sehr schön! Ich wollte bei meinem Kommentar schreiben, der Navigator treibt die Konversation... Begrifflichkeiten sind schwierig. Glaube es hängt wirklich stark vom (inneren) Bild ab. :)

---

Wenn man sich auf die Rollen versteift, kann es leicht passieren, dass diese plötzlich zum Mittelpunkt werden

Der Einwand klingt für mich sehr berechtigt aber ich scheine so etwas einfach noch nicht erlebt zu haben.

[codecop]

Meiner Erfahrung nach ist der Typist oft überfordert mit Typing alleine, also muss irgendwer sagen was zu tun ist und manchmal auch wie es zu tun ist. Leute fragen nicht um Hilfe. Daher stelle ich das am Anfang immer klar, dass Typing schwer genug ist und der Typist mehr "Hilfe" braucht. Ich muss das in den Sessions so 1-2 mal wiederholen wenn alles stumm ist und keiner etwas sagt.

[dertseha]

Ich bin mir nicht sicher, ob ich meine Vorgabe schlecht war und in eine nicht gewollte Richtung zwängte, oder ich einfach nur den Eindruck eines anderen Ergebnis habe.
Jedenfalls spannende Beiträge, danke Euch!

Es geht mir nicht darum die Rollen und/oder ihre Bezeichnungen abzuschaffen, sondern die übliche Erklärung auf die Frage "Was ist es?", dass nur 'Navigator' auf high-level unterwegs sein darf und 'Driver' nur auf low-level (wenn überhaupt) denken darf.
Das ist auch, was dieses verlinkte Paper als Aussage hat: beide sind auf ungefähr gleicher Abstraktionsebene unterwegs (bzw. "können bei adäquater Geübtheit sein" - und ja, Typist zu sein erfordert auch mehr Arbeit.

Meinen Vergleich mit dem group-programming-retreat ist, dass es wohl auch abhängig von der Erfahrung ist. Noch nie pair-programming: Navigator denkt, Driver tippt. Mehr Erfahrung: Driver darf auch mitdenken. Noch mehr: redet einfach miteinander.

Sozusagen, auf die Frage "Was ist Pair Programming?" möchte ich eher die allgemeine Antwort "Conversation with byproduct" geben und dann als zweite Antwort geben können "Wenn noch nicht so geübt: eine Person gibt vor, die andere folgt."
In diesem zweiten Satz ist die klassische "Navigator denkt groß" drinnen, als auch die "Driver erklärt/zeigt vor" Variante. Dann kann man noch immer verfeinern, wie zB "Wenn besser geübt, konstruktives code-review mit Verbesserung inklusive"

Nochmal anders formuliert: Als allgemeine Aussage will ich die "low level / high level" Trennung als erste und "einzige" Erklärung vermeiden - Als erster Eindruck brennt das mitunter falsche Vorstellungen ein - ob in der Technik, oder im Management. (Siehe auch Rea's "Rolle im Mittelpunkt" Kommentar)

[caichinger]

Es geht mir nicht darum die Rollen und/oder ihre Bezeichnungen abzuschaffen

Habe ich nicht so verstanden.

---

Danke für Beiträge, Erfahrungsberichte und Gedanken!

Danke @dertseha für den Stein des Anstoßes! Habe nicht mit so viel Input gerechnet und freue mich gerade darüber.

Habe gerae richtig Lust auf eine Pair oder Team Programming Session um die Situation/Dynamik noch einmal in Ruhe zu beobachten und diese Überlegungen hier auszuprobieren. Vielleicht ergibt sich das in Zukunft.

Ich werde mich nun aus der Diskussion ausklinken und das Thema später noch einmal für mich aufgreifen.

Wünsche euch bei dieser Gelegenheit einen ruhigen und erholsamen Jahresausklang und freue mich auf den Austausch im kommenden Jahr! 🎄 🍵 🛋️

[gregorriegler]

This Thread motivated my latest Blog Post: http://gregorriegler.com/2023/01/30/solo-programming-considered-bad.html