öffentlich
Redaktion Druckversion

Programmieren zu zweit?

Ein Code, zwei Programmierer - warum Paar-Programmierung effektiver und günstiger ist

5
(4)
Beitrag bewerten
Kommentar schreiben
Stand: 22. Februar 2012 (aktualisiert)

Zwei Programmierer an so einem kleinen Stückchen Code? Ist das nicht ein bisschen übertrieben? Nein, ist es nicht. Lorenz Hölscher erläutert, warum Paar-Programmierung besser für Ihre Projekte ist.

Was ist Paar-Programmierung?

Paar-Programmierung ist erst einmal nur genau das, was der Name verspricht: Statt einem sitzen zwei Programmierer am Code. Dabei ist es wichtig, dass sie nicht nacheinander oder virtuell daran arbeiten, sondern tatsächlich nebeneinander am gleichen Rechner.

Da ja nur einer von beiden wirklich die Finger an der Tastatur bzw. Maus haben kann, hat es sich eingebürgert, diesen als Piloten und den anderen als Navigator zu bezeichnen. Sie sind jedoch gleichberechtigt und sollen häufig (etwa alle Viertelstunde) die Rollen wechseln.

Außerdem ist es je nach Projektgröße auch sinnvoll, die Zusammensetzung der Paare ebenfalls regelmäßig zu verändern. Dadurch kommt immer wieder "frischer Wind" in die Zusammenarbeit und Programmierer sehen auch andere Teile des Projekts, was für das Verständnis oft wichtig ist.

Warum doppelt?

Auf den ersten Blick klingt es wie Ressourcen-Verschwendung, denn jeder der beiden Programmierer sollte gut genug sein, um die anstehenden Aufgaben alleine zu lösen. Dieser erste Blick vergisst aber, dass Code praktisch immer Fehler enthält. Manche davon sind offensichtlich und fallen direkt auf, andere sind schwieriger zu entdecken und kosten einige Zeit bis zur Lösung und schließlich gibt es kritische Fehler, die erst eine Katastrophe auslösen, bevor sie bemerkt werden.

Wenn Sie mal realistisch zusammenzählen, wie viel Zeit eigentlich für die Entdeckung von Fehlern, die Suche nach deren Ursache und den Aufwand zur Behebung verschleudert wird, ist Paar-Programmierung plötzlich eine preiswerte Lösung. Stellen Sie sich vor, Sie schreiben eine Prozedur, Aufwand 10 Minuten. Falls diese aber später mal einen Fehler verursacht, glauben Sie, dass das in ebenfalls 10 Minuten behoben wäre?

Vor allem müssen Sie diese Prozedur erst einmal als Fehler verursachend identifizieren. In größeren Projekten geht da locker die erste halbe Stunde für drauf. Dann müssen Sie sich wieder in die nun als problematisch erkannte Prozedur eindenken, was die nächsten 5-10 Minuten dauert. Dann soll Ihnen die Lösung des Problems einfallen und das will dann auch mehrfach noch getestet werden. Macht zusammen schon in einfachen Fällen locker eine Stunde Aufwand.

Jetzt rechnen Sie mal den Zeitaufwand für diese fehlerfreie Prozedur zusammen:

  • Zwei Programmierer arbeiten je 10 Minuten gemeinsam daran = 20 Minuten.

  • Ein Programmierer schreibt alleine 10 Minuten und sucht später eine Stunde nach Fehlern = 70 Minuten.

Sehen Sie, warum Paar-Programmierung doch preiswerter ist? Mal abgesehen davon, dass Ihr Ruf beim Kunden mit jedem entdeckten Fehler leidet.

Was ändert sich?

Vordergründig scheint nur der Zeitaufwand verdoppelt zu werden, weil nun gleich zwei Programmierer vor dem Code sitzen, den bisher ein einzelner geschrieben hat. Tatsächlich passiert aber noch einiges mehr:

  • Während einer programmiert, prüft der andere automatisch, ob er das nicht anders schreiben würde und warum. Dadurch steigt die Code-Qualität enorm, weil Fehler direkt entdeckt werden. Vor allem die strukturellen und damit weniger offensichtlichen Probleme, die später den übelsten Ärger auslösen, werden durch das Mitlesen sofort entlarvt.

  • Weil beide am Code arbeiten, gibt es mehr Mitarbeiter, die sich tatsächlich mit dem Projekt auskennen. Sowohl in der Kundenbetreuung als auch in Urlaubszeiten ist immer jemand erreichbar, der weiß, worum es geht.

  • Beide Programmierer denken über Algorithmen nach und kommen so schneller auf bessere Lösungen. Gleichzeitig bleibt das Wissen nicht bei einem einzigen Mitarbeiter, sondern es findet automatisch eine gleichmäßige Know-how-Verbesserung statt.

Oftmals gar nicht so richtig wahrgenommen werden die sozialen Veränderungen, die damit einhergehen:

  • Die Phasen, in denen einzeln arbeitende Kollegen aus dem Fenster gucken, privat telefonieren oder ein bisschen im Internet herumgoogeln, fallen fast vollständig weg. Einer von beiden ist immer aktiver und reißt den anderen mit.

  • Der Zusammenhalt in der Firma wird besser, weil es weniger offensichtliche Teilgruppen gibt. Jeder muss mit jedem anderen wenigstens zeitweise zusammenarbeiten und dadurch Kontakte knüpfen.

  • Es macht mehr Spaß.

  • Wer den Code mitentwickelt hat, kann ehrlichere Wertschätzung liefern, als jemand, der später nur mal draufguckt und "schön, schön" murmelt.

Vor allem diese letzten Argumente sind viel überzeugender, als Sie auf den ersten Blick vielleicht vermuten mögen. Was zuerst wie soziale Kontrolle und gnadenloser Zwang zur Code-Abstimmung aussieht, ist in Wirklichkeit eine erhebliche Verbesserung der Arbeit.

Erfahrung sammeln

Ich bin eher zufällig in die Paar-Programmierung hineingerutscht und habe ein paar Monate lang zu zweit programmiert. Es ist nicht nur viel effektiver, weil man nicht so lange über Nebensächlichkeiten nachdenkt, sondern es macht auch schlicht mehr Spaß. Vor allem kann man viel voneinander lernen, ohne dass es extra ein Seminar braucht. Trotz der Diskussionen um den richtigen Algorithmus oder auch nur die Datentypen der Variablen wird man meistens schneller fertig.

Nebenbei werden übrigens aktiv agierende Programmier-Paare viel seltener durch Zwischenfragen gestört als Mitarbeiter, die alleine vor ihrem Rechner sitzen. Auch das beschleunigt die Arbeit, zumal bei doch auftretenden Störungen meistens einer im Thema bleibt und nur der andere antworten muss.

Schwierigkeiten

Es wäre unglaubwürdig, wenn es nicht irgendwie auch Nachteile bei einem Konzept gäbe. Aber es sind wenige und vor allem lösbare:

  • Sie arbeiten dabei stundenlang mit einem Kollegen zusammen. Wenn Sie den nicht leiden können, ist das nervenaufreibend.

  • Das Programmierpaar redet sehr viel, muss also sinnvollerweise einen eigenen Raum haben, damit die anderen nicht gestört werden.

Das alles ist aber nicht so schlimm, wie es sich vielleicht anhört. Wenn Sie einen Kollegen nicht leiden können, ist schon der Aufenthalt im gleichen Büro störend. Das sollten Sie sowieso irgendwie klären. Ebenso ist das dauernde Reden auch nicht schlimmer, als wenn jemand im gleichen Raum oft telefoniert.

Fazit

Paar-Programmierung löst natürlich nicht alle Probleme, die es in kleinen Programmier-Firmen gibt. Aber auf dem Weg zu schneller, effizienter und vor allem erheblich fehlerreduzierterer Programmierung ist es eine sehr geeignete Methode.

Beitrag bewerten

Ihre Wertung:

 

Hallo,

kurz, knackig, einleuchtend – und vor allem sehr praxisnah im Alltagsgeschäft eines Programmierers geschildert.

Wikipedia weiß zu XP (Extreme Programming) zu sagen: "Programmierer weisen oftmals ein recht ausgeprägtes Ego auf, das sich in großer Überzeugung von „richtigen Lösungen“ und einem gewissen Besitzdenken hinsichtlich des geschriebenen Codes äußert. Nicht alle Programmierer können damit umgehen, dass - gemäß XP - jeder den Code aller anderen modifizieren darf."

Dennoch nutzt das stark lösungsorientierte XP das von Ihnen geschilderte Pair Programming:

"Bei Paarprogrammierung (engl. Pair Programming) handelt es sich um eine Arbeitstechnik, die sich häufig bei agilen Vorgehensweisen zur Softwareentwicklung findet. So ist Paarprogrammierung beispielsweise ein wichtiger Bestandteil von Extreme Programming (XP)."

... wodurch sich mehr Entwickler mit ein und demselben Code identifizieren dürfen, was Änderungen weniger zur Reviermarke macht.

Ein durchaus wichtiger und sympathischer Ansatz, den Sie da beschreiben, auch und besonders der soziale Aspekt wird m.E. oft "pekuniär" unterschätzt ;)

Die allgemeine Produktivität im Entwicklerteam steigt insbesondere deswegen nach meinen Erfahrungen enorm und manch ein "Konflikt" löst sich oft schon dadurch, dass die "Parteien" neutral und sachgebunden zu aktivem sozialem Handeln angeregt werden.

Mit freundlichen Grüßen
Peter Neelmeyer

Mitglied werden, Vorteile nutzen!

  • Sie können alles lesen und herunterladen: Beiträge, PDF-Dateien und Zusatzdateien (Checklisten, Vorlagen, Musterbriefe, Excel-Rechner u.v.a.m.)
  • Unsere Autoren beantworten Ihre Fragen

Downloads zu diesem Beitrag

Newsletter abonnieren