Pair Pro­gramming: 4-Augen-Prinzip in der Software-Ent­wick­lung

Die Ent­wick­lung von neuer Software ist ein auf­wän­di­ges Un­ter­fan­gen. Abhängig vom Umfang des Programms müssen sehr viele Even­tua­li­tä­ten, Funk­tio­nen und Pro­blem­stel­len be­rück­sich­tigt werden. Da können selbst geübte Software-Ent­wick­ler die Ori­en­tie­rung verlieren. Damit die Pro­gram­mie­rung möglichst effizient verläuft, gleich­zei­tig aber feh­ler­frei­er Code entsteht, hat man in den letzten Jahren und Jahr­zehn­ten moderne Ar­beits­me­tho­den ent­wi­ckelt: Scrum und Kanban dienen bei­spiels­wei­se dem Zweck, das komplette System zu ver­bes­sern.

Etwas weniger groß angelegt ist Pair Pro­gramming: Ent­wick­ler arbeiten dabei immer zu zweit am Code. Wie kann das funk­tio­nie­ren und was sind die Vorteile dieser Ar­beits­wei­se?

Die Methode der Paar­pro­gram­mie­rung wird vor allem bei agiler Software-Ent­wick­lung genutzt und konkret beim Extreme Pro­gramming (XP) gefordert. Beim Pair Pro­gramming arbeiten immer zwei Menschen gleich­zei­tig am Code, sitzen also im besten Fall direkt ne­ben­ein­an­der. Einer schreibt den Code, der andere überprüft diesen in Echtzeit. Gleich­zei­tig tauschen sich beide stetig aus: dis­ku­tie­ren Probleme, finden Lö­sungs­we­ge, ent­wi­ckeln kreative Ideen.

Nor­ma­ler­wei­se kommen den beiden Mit­ar­bei­tern zwei un­ter­schied­li­che Rollen zu: Der als Pilot be­zeich­ne­te Pro­gram­mie­rer schreibt den Code. Der so­ge­nann­te Navigator überprüft diesen. Es gehört zu den Pair-Pro­gramming-Regeln, dass beide re­gel­mä­ßig (und zwar in kurzen Ab­schnit­ten) die Rollen tauschen. Das ver­hin­dert ein hier­ar­chi­sches Gefälle: Beide sind gleich­be­rech­tigt und können daher auch pro­blem­los in die Rolle des jeweils anderen schlüpfen.

Auch der Ar­beits­platz sollte dabei idea­ler­wei­se an die An­for­de­run­gen des Pair Pro­grammings angepasst sein. So haben beide Partner Maus, Tastatur und einen eigenen Monitor zur Verfügung, wobei die Bild­schir­me jeweils das gleiche anzeigen.

Etwas un­ge­wöhn­li­cher ist hingegen das so­ge­nann­te Remote Pair Pro­gramming. Hierbei sitzen die Pro­gram­mier­part­ner nicht ne­ben­ein­an­der, sondern an komplett un­ter­schied­li­chen Orten. Damit das funk­tio­nie­ren kann, bedarf es spe­zi­el­ler tech­ni­scher Lösungen. Die Kollegen müssen in der Lage sein, trotz der Ent­fer­nung direkt mit­ein­an­der zu kom­mu­ni­zie­ren, auf den Code zu­zu­grei­fen und Än­de­run­gen in Echtzeit zu sehen.

In der Praxis arbeiten oftmals zwei Ent­wick­ler mit un­ter­schied­li­chem Er­fah­rungs­le­vel zusammen: So kann ein Pro­gram­mie­rer mit viel Ar­beits­er­fah­rung seinem jüngeren Kollegen direkt in der Praxis Know-how mitgeben. Der Junior-Mit­ar­bei­ter auf der anderen Weise hat viel­leicht frische Ideen, die er in das Projekt ein­brin­gen kann.

Aber auch die Kom­bi­na­ti­on von zwei Kollegen aus un­ter­schied­li­chen Bereichen kann fruchtbar sein: Arbeitet ein klas­si­scher Pro­gram­mie­rer mit einem Designer zusammen, können sich beide mit ihrer je­wei­li­gen Expertise un­ter­stüt­zen.

Pair Pro­gramming ist vor allem bei größeren Projekten sinnvoll. Denn bei riesigen Mengen an Code, die zudem re­gel­mä­ßig geändert werden, ist das Vier-Augen-Prinzip besonders wirksam. So kann man si­cher­ge­hen, dass immer die best­mög­li­che Version eines Ab­schnitts in den Quelltext eingeht, wodurch weniger Nach­bes­se­run­gen notwendig sind und die Feh­ler­zahl abnimmt. Das nach­träg­li­che Über­prü­fen von sehr langen Quell­codes ist zeit­auf­wen­dig und mühsam, weswegen es vor­teil­haft ist, ihn schon möglichst zu Beginn feh­ler­frei anzulegen.

Es ist übrigens nicht notwendig, dass – auch innerhalb eines Projekts – immer die gleichen Kollegen zu­sam­men­ar­bei­ten. Tat­säch­lich ist es sogar von Vorteil, wenn die Paarungen re­gel­mä­ßig neu gemischt werden. So bekommt jedes Team­mit­glied einen guten Einblick in den kom­plet­ten Quelltext. Durch hängt der Erfolg des Projektes auch nicht so stark von Ein­zel­per­so­nen ab. Fällt eine Person aus, ist nicht das ganze Projekt gefährdet, denn alle anderen können den Ausfall kom­pen­sie­ren.

Arbeitet man zu zweit an einem Projekt – egal, ob es um Pro­gram­mie­rung geht oder ein anderes Vorhaben – hat das grund­sätz­lich viele Vorteile. Vier Augen sehen meist mehr als zwei: Das Risiko von Fehlern wird durch Pair Pro­gramming minimiert. Während die eine Person schreibt, hat die andere den Code im Blick und kon­zen­triert sich nur darauf, Fehler zu finden. Es ist oft schwer, seine eigenen Fehler zu entdecken. Ein Kollege entdeckt Un­stim­mig­kei­ten oft viel schneller.

Zudem ist aber auch die sich durch die Kom­mu­ni­ka­ti­on ent­wi­ckeln­de Krea­ti­vi­tät ein großer Vorteil: Durch den ständigen Austausch des Pro­gram­mier­ge­spanns kommen Ideen zustande, auf die man allein womöglich nicht gekommen wäre. Der kom­mu­ni­ka­ti­ve Austausch der beiden Partner sorgt auch dafür, dass man in kürzerer Zeit auf bessere Pro­blem­lö­sun­gen kommt. Denn während eine Ein­zel­per­son sich mög­li­cher­wei­se mit der erst­bes­ten Option zu­frie­den­gibt, muss man seine Ent­schei­dun­gen beim Pair Pro­gramming immer gegenüber dem Kollegen recht­fer­ti­gen. Dieser hat aber viel­leicht eine andere Sicht auf das Problem und ist deshalb mit der vor­ge­schla­ge­nen Lösung nicht zufrieden. Durch die sich daraus ergebende Dis­kus­si­on kommen oft Ideen für deutlich besseren Code zustande.

Guter Code ist letztlich auch schlanker Code: Die Erfahrung hat gezeigt, dass Quelltext, der beim Pair Pro­gramming entsteht, oft kürzer und damit ef­fi­zi­en­ter gestaltet ist. Das spart später Res­sour­cen bei der Wartung und Um­ar­bei­tung.

Wie erwähnt, kann man die Technik auch anwenden, damit erfahrene Mit­ar­bei­ter ihr Wissen an jüngere Kollegen wei­ter­ge­ben können. So pro­fi­tiert man nicht nur von dem ei­gent­li­chen Vorteil des Pair Pro­grammings – der Erzeugung von qua­li­ta­tiv hoch­wer­ti­gem Code –, sondern kann die Methode gleich­zei­tig auch für Aus­bil­dungs­zwe­cke nutzen.

Das Ganze kostet al­ler­dings sehr viel Zeit: Zwar arbeiten zwei Pro­gram­mie­rer durchaus schneller zusammen als einer allein, aber eben nicht so schnell wie zwei Pro­gram­mie­rer, die separat arbeiten. Das bedeutet, dass mit dieser Methode Projekte entweder langsamer vor­an­schrei­ten oder man mehr Personal ein­stel­len muss, was wiederum zu erhöhten Kosten führt. Die Ver­fech­ter von Pair Pro­gramming gehen al­ler­dings davon aus, dass diese an­fäng­li­che Mehr­ar­beit sich im Nach­hin­ein rechnet: Da der so ent­stan­de­ne Code weniger Fehler enthält und insgesamt besser struk­tu­riert ist, fällt die War­tungs­ar­beit sehr viel geringer aus.

Ein weiterer möglicher Nachteil: Pair Pro­gramming eignet sich zwar für das Team­buil­ding, aber auch nur dann, wenn die beiden Kollegen gut mit­ein­an­der arbeiten können. Die beiden Mit­ar­bei­ter müssen so eng mit­ein­an­der agieren, dass per­sön­li­che Probleme un­ter­ein­an­der entweder zum lang­sa­me­ren Vor­an­kom­men führen oder in einer kom­plet­ten Es­ka­la­ti­on münden. Deshalb sollte man Mit­ar­bei­ter bei dieser Methode nicht wahllos zu­sam­men­wür­feln. Zwar ist es ideal, wenn jeder mal mit jedem anderen Kollegen zu­sam­men­ge­ar­bei­tet hat, doch das funk­tio­niert nur dann, wenn das ganze Team gut har­mo­niert.