Softwareentwicklung

Das Experiment: Ist Pair Programming wirklich sinnvoll?

Melanie Feldmann

© Shutterstock / mimohe

Das Thema Pair Programming entfacht immer wieder die Gemüter. Für manche ist es ein wunderbares Werkzeug den Code und die eigenen Fähigkeiten durch einen Mit-Entwickler zu verbessern. Für andere ist es die pure Hölle bei jedem getippten Zeichen beobachtet zu werden. Das polnische Entwicklungsunternehmen EL Passion hat die Probe aufs Exempel gemacht und ein Pair-Programming-Experiment gestartet.

Die Entwickler von EL Passion wollten prüfen, ob es wirklich stimmt, das Programmierer, die in Paaren arbeiten, produktiver und effizienter sind. Die meisten Daten rund um das Thema beurteilen sie als unzutreffend – einen Entwickler kann man nicht an Codezeilen pro Monat bewerten – oder schlicht und einfach für zu alt.

Sie starteten ein Experiment: zwei Teams arbeiteten volle zwei Wochen an jeweils zwei Projekten. Team A startete mit Solo-Entwicklern, Team B arbeitete mit Pair Programming. In der zweiten Woche wechselte Team A zu Pair Programming und Team B zu Solo – jeweils mit neuen Projekten. In den zwei Wochen wurden die Schnelligkeit, die Codequalität und die Anzahl der Bugs täglich gemessen. Außerdem gaben die Entwickler am Ende des Experiments auch ihre ganz persönlichen Erfahrungen zu Protokoll. Den Aufbau des Experiments beschreibt Mateusz Glapiński, Digital Marketing Manager bei EL Passion, im Blog des Unternehmens.

„Es war anstrengend!“

Das erste Ergebnis: Die Entwickler waren in Paaren deutlich fokussierter bei der Arbeit als alleine. Sie checkten ihre E-Mails und Facebook seltener, sie ließen sich weniger von Geräuschen und anderen Kleinigkeiten ablenken. Der berühmtberüchtigte Flow war einfach zu erreichen und auch zu halten. So konzentriert zu arbeiten hat jedoch auch seinen Preis: Es ist anstrengend.

Ein positiver Effekt war auch, dass Pair Programming die Kommunikation verbesserte. Entwickler, die sich nicht immer an die Regeln halten, waren einfacher zu managen. Und ein Team auf schlechte Code-Qualität anzusprechen war entspannter als eine Einzelperson dafür verantwortlich zu machen. Nicht nur die verbale Kommunikation gewann. Es kam auch zu mehr Code Reviews auf GitHub in den Teams, die zuerst in Paaren und dann alleine programmierten. Dadurch dass die Entwickler ihren Code und ihre Lösung direkt erklären mussten, verteilte sich das Wissen über das gesamte Projekt über das Team. Und auch die einzelnen Entwickler lernten schneller und besser.

Aber sie beobachteten auch Nachteile. Wenn es in der Solo-Woche zu Kommunikationsproblemen kam, eskalierten diese meist in der Paar-Woche. Außerdem sank die Produktivität, wenn sich ein Entwickler-Pärchen zu gut verstand. Hier war wieder zu viel Ablenkung im Spiel.

Die Dos and Don’ts des Pair Programming

Die Erkenntnisse aus dem Experiment lassen sich kurz und knackig zusammenfassen:

  • In Paaren zu arbeiten ist anstrengend. Pair Programming sollte nicht die ganze Zeit über angewandt werden.
  • Paare sollten sich nicht zu sehr mögen. Es sollte aber auch keine große Abneigung zwischen ihnen herrschen.
  • Paare sollten aus Entwicklern mit unterschiedlichen Erfahrungsleveln bestehen, damit sie am meisten voneinander lernen.
  • Pair Programming eignet sich am besten für anspruchsvollere Probleme. Sonst wird dem zweiten Entwickler schlicht langweilig beim Zusehen.
  • Niemanden zum Pair Programming zwingen. Aber Entwickler dabei unterstützen es auszuprobieren.

Auch die Ergebnisse diskutiert Glapiński ausführlich im Blog.

Aufmacherbild: Four hands von Shutterstock / Urheberrecht: mimohe

Geschrieben von
Melanie Feldmann
Melanie Feldmann
Melanie Feldmann ist seit 2015 Redakteurin beim Java Magazin und JAXenter. Sie hat Technikjournalismus an der Hochschule Bonn-Rhein-Sieg studiert. Ihre Themenschwerpunkte sind IoT und Industrie 4.0.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: