Die größte Herausforderung unserer Zeit

Wenn ich Sie jetzt fragen würde “Was ist die größte Herausforderung unserer Zeit?”, was würden Sie antworten? Wahrscheinlich beschäftigen wir uns alle mit den unterschiedlichsten Dingen. Wir setzen wahrscheinlich auch alle unterschiedliche Schwerpunkte und Prioritäten in unserem Leben. Aber ich glaube ein Thema ist dabei besonders wichtig. Je nachdem wie erfolgreich wir uns mit diesem Thema auseinandersetzen bestimmt, wie viel Erfolg, Freude und Erfüllung wir erleben. Ich habe mir die eingangs gestellte Frage auch gestellt und beantwortet: Ich bin der Meinung, die größte Herausforderung unserer Zeit ist,

wie wir unsere Zeit einteilen, um eine gute Balance zwischen
Arbeit, Hobbies, Familie & Freunde und Gesundheit zu finden.

Vielleicht erinnern diese Punkte uns an die fünf Grundbedürfnisse, insbesondere an physiologische, soziale und individuelle Bedürfnisse. Aber während da der Fokus auf was uns wichtig ist und was wir brauchen liegt, geht es bei den vier genannten Kategorien um wo wir Zeit investieren müssen. Unsere Bedürfnisse bestimmen diese Punkte und priorisieren sie. Wenn wir uns dann mit den genannten Aspekten beschäftigen, tragen wir zu der Befriedigung unserer Bedürfnisse bei.

Es gibt Dinge, die nicht eindeutig einer Kategorie zugeordnet werden können, oder die alle Kategorien betreffen. Hier soll es aber eher um die Punkte gehen, die gegenseitig um unsere Zeit konkurieren. Um zwischen diesen eine Balance zu finden, müssen wir die uns zur Verfügung stehende Zeit einteilen. Unsere Tage haben 24 Stunden. In einer Woche arbeiten wir in der Regel 5 Tage und haben dann 2 Tage Wochenende. Was machen wir damit? Ein einfaches Rechenbeispiel könnte so aussehen:

168 Stunden pro Woche
– 56 Stunden schlafen (7 * 8 Stunden)
– 3 Stunden Sport (3 * 1 Stunden)
– 7 Stunden Körperhygiene (7 * 2 * 0.5 Stunden)
– 3.5 Stunden Frühstück (7 * 0.5 Stunden)
– 3.5 Stunden Abendessen (7 * 0.5 Stunden)
– 2 Stunden Mittagessen am Wochenende (2 * 1 Stunden)
– 40 Stunden im Büro (5 * 8 Stunden)
– 5 Stunden Mittagspause (5 * 1 Stunden)
– 5 Stunden Büro An- und Abfahrt (5 * 2 * 0.5 Stunden)
= 43 restliche Stunden für Mitmenschen und Hobbies

Ich könnte hier jetzt weiter rechnen und die bestehende Zeit noch auf Familie, Freunde und Hobbies aufteilen. Aber es geht mir hier nicht um ein Rezept für ein ausgeglichenes Leben. Ich glaube es gibt dafür kein allgemeines Rezept, zumindest kenne ich keins. Wenn wir eine Balance zwischen Arbeit, Hobbies, Familie & Freunde und Gesundheit erreichen wollen, müssen wir eine persönliche Zeitplanung für unser Leben vornehmen. Wenn wir es nicht tun und nicht versuchen unsere Zeit einzuteilen, dann werden eine oder mehrere Kategorien zu kurz kommen. Die darunter liegenden Bedürfnisse werden dann nicht befriedigt und wir werden zunehmend unglücklicher. Zeit ist unser bestes Werkzeug, deswegen lasst es uns weise nutzen.

Das ist die größte Herausforderung unserer Zeit.

 

Zeit ist das Element, in dem wir existieren. Wir werden entweder von ihr dahin getragen oder ertrinken in ihr.
~Joyce Carol Oates

 

 

Advertisements

The Dark Side of Pair Programming

Pair Programming bezeichnet das Entwickeln von Software zu zweit. Das hat laut [1] viele Vorteile: Die Qualität der Software wird verbessert, Fehler werden früh erkannt, man hat mehr Spaß an der Arbeit, Wissen verbreitet sich im gesamten Team und die Kommunikation im Team verbessert sich. Doch all das funktioniert nicht automatisch. Man bekommt diese Vorteile nicht automatisch wenn man zu zweit vor dem Computer sitzt. In [2] werden beispielsweise häufige Schwierigkeiten beim Pairing beschrieben.

Probleme

In diesem Blogpost möchte ich von meinen negativen Erfahrungen und Beobachtungen mit Pair Programming berichten. Zu jedem Punkt möchte ich auch Maßnahmen vorschlagen, die zu einer Verbesserung führen können.

  Zeit-intensiv

Pair Programming kostet Zeit. Das ist besonders bei heterogenen Pairs der Fall. Man bremst sich aus indem man erklärt und diskutiert. Viele Diskussionen neigen dazu abzudriften und zu längeren Grundsatzdiskussionen zu werden. Das ist sehr frustrierend, weil man beschäftigt sich viel mit sich selbst und mit Meinungen, statt mit den Problemen, die man eigentlich lösen will.
Mitigation: Man sollte größere Diskussionen verschieben und besser in der Retrospektive diskutieren. Außerdem könnte man versuchen homogenere Pairs zu bilden. Man könnte hier auch einen dritten Programmierer dazu nehmen (Mob Programming [3]), nicht um mitzudiskutieren, sondern um schonmal weiter arbeiten zu können, während zwei sich zum diskutieren ausklinken.

  Kontext-Switches

Wenn beide Pairing Partner kreativ sind, haben auch beide viele Ideen, die sie ausprobieren wollen. Besonders wenn einer von der Idee des anderen nicht überzeugt ist, aber keine Gegenargumente hat und auch keine Diskussion anfangen möchte, wird er die Idee ausprobieren lassen. Oder wenn einer googeln und der andere dekompilieren will. Das Ausprobieren einer eigenen Idee muss in beiden Fällen dann erstmal warten. Man bremst sich auch hier wieder gegenseitig aus. Unterschiedliche Lösungsansätze können nicht gleichzeitig verfolgt werden sondern müssen synchronisiert werden. Das führt in kreativen Phasen zu viel teurem Hin und Her, weil man muss ja wieder reverten oder den Branch wechseln.
Mitigation: Man sollte in diesen Fällen einen zweiten Computer am selben Schreibtisch benutzen. Dann könnte das Ausprobieren von Ideen besser parallelisiert werden.

  Anstrengend

Durch Erklärungen, Diskussionen und Vorschläge steigt die Lautstärke im Büro. Das kann in Großraumbüros das Arbeiten anderer, auch Pairs, stören. Außerdem neigen Pairs dazu, sich gegenseitig unter Druck zu setzen, sodass sich beispielsweise keiner mehr traut kurz aufzustehen oder eine kreative Pause einzulegen. Ich finde es gut, das Pair Programming in vielen Fällen Prokrastination verhindert, aber schlecht, wenn man keine Zeit oder Ruhe mehr zum Nachdenken hat. Wenn einer sich tief reindenken will, wird das massiv erschwert, wenn der andere ihn durch den Code hetzt, erklärt und diskutiert.
Mitigation: Man sollte regelmäßige Pausen fest einplanen, zum Beispiel mit dem Pomodoro-Timer [4]. Zum Nachdenken könnte man sich auch kurzzeitig in ein anderes Büro zurückziehen.

  SOZIALE REIBUNG

Unterschiedliche Ansichten und Vorlieben führen häufig dazu, dass man sich gegenseitig kritisiert und verletzt. Das führt zu persönlichen Spannungen und häufig auch zu Kompromissen, mit denen keiner richtig zufrieden ist. Man hat dann den Eindruck, beide Pairing Partner würden in unterschiedliche Richtungen ziehen. Und wenn man erstmal unglücklich ist, wird alles noch viel schlimmer.
Mitigation: Wir sollten uns neu bewusst machen, worum es eigentlich geht. Es geht um die Bedürfnisse und Interessen des Kunden und nicht um unsere eigenen. Das ist Kundenorientierung. Oft fehlt uns die richtige Perspektive, wenn wir über Code diskutieren und beleidigt sind, wenn er zu Recht oder zu Unrecht kritisiert wird. Wir sollten uns etwas weniger wichtig nehmen [5]. Dan North empfiehlt die emotionale Verbindung, die wir oft zu unserem Code haben, auf die Bedeutung der Software für die Nutzer zu verlagern [6].

Let’s care less about the beauty of the code and more on the impact on success and happiness of the users. Software is the means to the end. As little software as needed to get there.
~ Dan North

  Soziales Faulenzen

Laut Agile Alliance [2] ist das größte und häufigste Problem, dass Entwickler während der Pairing Sitzung nicht gleichermaßen engagiert arbeiten. Das kann dazu führen, das sich einer zurücklehnt, passiv wird und mit den Gedanken zunehmend woanders ist. Spätestens wenn er das Handy zückt hat er sich abgemeldet. Aber selbst wenn beide aktiv bleiben, gibt es einen Leistungsabfall der beteiligten Personen [7]. Sobald die Leistung des Einzelnen nicht mehr sichtbar ist, sondern nur noch die der Gruppe, sinkt die Leistung des Einzelnen in einer Zweiergruppe auf 93%. Je mehr Personen beteiligt sind, desto weniger investieren diese in die Erreichung des gemeinsamen Ziels und verlassen sich zunehmend auf die Gruppe. Verantwortung wird weniger übernommen, sodass man sich hinter Beschlüssen der Gruppe versteckt. Außerdem trifft die Gruppe risikoreichere Entscheidungen weil niemand die ganze Schuld trägt. Beim Pair Programming führt das dazu, dass beide Entwickler oberflächlicher arbeiten. Man fühlt eine trügersiche Sicherheit, da der andere die Lösung auch gut findet und keine Probleme sieht.
Mitigation: Um die Pairing Partner an gleichmäßiges Engagement zu erinnern, kann ein Tool wie der Pair Activity Monitor unterstützen. Das Tool stellt Tastatur- und Mausaktivität beider Pairing Partner gegenüber. Dadurch wird ein großer Teil der Leistung wieder sichtbar. Metriken wie Tastaturanschläge oder Lines Of Code sind zwar keine aussagekräftigen Indikatoren für Software-Qualität, aber sie eignen sich hervorragend um Leistungdifferenzen innerhalb eines Pairs zu visualisieren. Gute Ideen und gedankliche Leistung werden davon natürlich nicht berücksichtigt. Diese sollten explizit einer Person zugeschrieben und entsprechend erwähnt werden.

Personas

Neben den oben beschriebenen negativen Erfahrungen mit Pair Programming sind mir im Laufe der Zeit verschiedene immer wiederkehrende Verhaltensweisen aufgefallen. Auch bei mir selber. Diese Verhaltensweisen, die ich alle als störend empfinde, möchte ich hier in Form von Personas einmal zusammenfassen. Damit sind keine bestimmten Personen, sondern archetypische Charaktere gemeint.

  • Der Abgelenkte
    spielt mit dem Handy, ist gedanklich woanders und lenkt andere mit Fragen oder Geschichten ab.
    Mitigation: Driver-Navigator-Balance, stehend am Whiteboard denken/lösen
  • Der Zuschauer
    schaut einfach nur zu und sagt nichts. Hat auch keine Ideen und kein Interesse.
    Mitigation: Driver-Navigator-Balance, nach Meinung fragen, abholen wenn abgehängt
  • Der Neue
    kennt sich noch nicht gut aus, traut sich noch nicht zu sagen was er denkt. Er fragt lieber viel.
    Mitigation: Ego Suspension
  • Der Bedachte
    lässt sich viel Zeit, denkt mehr und schreibt weniger.
    Mitigation: am Whiteboard denken/lösen (Versuchung abzuhängen ist geringer)
  • Der Eigensinnige
    macht alles selbst und lässt niemanden an die Tastatur. Er entscheidet alleine oder hat schon entschieden.
    Mitigation: Driver-Navigator-Balance, zweiter PC, Ego Suspension, Vorhaben klar kommunizieren und erst dann coden
  • Der Lehrer
    redet viel und erklärt alles über-ausführlich.
    Mitigation: Verständnis äußern, weiter arbeiten, Ego Suspension
  • Der Wichtige
    wird andauernd von irgendjemand gefragt oder geholt. Er weiß viel und hat viel Erfahrung.
    Mitigation: geheimes Büro/Besprechungszimmer
  • Der Überzeugte
    beharrt auf seinem Standpunkt und seiner Sicht der Dinge. Es ist extrem schwer ihn zu überzeugen.
    Mitigation: Ego Suspension
  • Der Hetzer
    braucht keine Ruhe und scheucht den Partner durch den Code (“scroll nochmal nach oben”, “nochmal zurück”), obwohl der gerade etwas anderes nachsehen will. Besonders beim Debuggen.
    Mitigation: Driver-Navigator-Balance, Vorhaben klar kommunizieren und erst dann loslegen
  • Der Alternative
    raucht viel und duscht selten. Sein Tisch und seine Tastatur sind versifft. Er will immer an seinem PC pairen.
    Mitigation: zweiter PC, mehr Abstand

Auch ich erkenne mich von Zeit zu Zeit in einer der beschriebenen Personas wieder. Dabei ist es mir doch wichtig zu einem effizienten und produktiven Arbeitsumfeld beizutragen. Wir müssen uns immer wieder neu daran erinnern und versuchen, möglichst wenig soziale Reibung zu erzeugen und stattdessen gute und engagierte Pairing Partner sein.

Fazit

Gute und konstruktive Pairs sind nicht selbstverständlich. Ich habe einige Probleme und nachteilige Verhaltensweisen beschrieben, die die eingangs erwähnten Vorteile sehr schnell zunichtemachen. Wir müssen uns fragen: Bekommen wir die Vorteile wirklich? Wenn nicht, ist Pair Programming teure Zeit- und Energieverschwendung.

Wenn Pairs sich viel mit sich selbst beschäftigen, nicht gleichermaßen engagiert arbeiten oder die Effekte des sozialen Faulenzens deutlich werden, sollte sich etwas ändern. Und wenn es nicht möglich ist gute Pairs zu bilden, dann ist es sinnvoller nicht zu pairen. Da man die Vorteile nicht hat, gibt es auch keinen Grund mit angezogener Handbremse zu fahren. So ist man wenigstens schneller fertig. Wenn wir aber pairen, dann wollen wir gute Pairing Partner sein um gemeinsam mehr zu erreichen, als wir alleine erreicht hätten.

Don’t try to be right. Try to be helpful. Try to be useful.
~ James Wells

 

 

 

Links

[1] https://www.it-agile.de/wissen/agiles-engineering/pair-programming/
[2] https://www.agilealliance.org/glossary/pairing/
[3] http://mobprogramming.org/
[4] https://en.wikipedia.org/wiki/Pomodoro_Technique
[5] http://www.johnniland.com/suspension-of-ego/
[6] http://dotnetrocks.com/?show=1118
[7] https://en.wikipedia.org/wiki/Social_loafing