Twincoding Light

Twincoding ist eine der "Empfehlungen" der Xtreme Programming Methodik. Twincoding heißt, dass 2 Programmierer vieles zusammen programmieren.

Aber kann man es sich überhaupt leisten zwei Programmierer mit der gleichen Sache zu beschäftigen? Ich kann ja nicht meinem Kunden sagen: Bei uns ist alles doppelt so teuer, weil wir Twincoding machen. Twincoding muss, um überhaupt konkurrenzfähig zu sein, mindestens so produktiv sein, wie Einzelcoding. Das ist nicht einfach, aber möglich.

Die Theorie sagt, dass man Programmierfehler vermeiden kann durch das zweite Augenpaar. Die Vermeidung der Fehler wiegt den Mehraufwand wieder auf. Das kann nur stimmen, wenn man beim Twincoding keine Fehler macht und beim Einzelcoding mindestens 50 % der Zeit ineffizient mit Fehlern und Problemen verbringt, die man zu zweit nicht gehabt hätte.

Die Annahme, dass beim Twincoding keine Fehler auftreten ist sicher nicht ganz richtig. Teilen wir die Fehlerzeiten ein in Flüchtigkeitsfehler, Denkfehler und Blockaden. Flüchtigkeitsfehler kosten sehr oft wenig Zeit. Sie fallen meist schon beim Compilerlauf auf und werden schnell behoben. Dafür geht es aber um sehr viele Ereignisse. Flüchtigkeitsfehler werden bei Twincoding tatsächlich stark unterdrückt. Hier liegt Twincoding klar vorne. Die Behebung von Denk- und Architekturfehlern kostet wesentlich mehr Zeit, als die von Flüchtigkeitsfehlern. Und nicht nur die Korrektur kostet Zeit, sondern auch die Produktion des Fehlers. Erfahrungsgemäss reduziert sich die Wahrscheinlichkeit für Denkfehler deutlich, aber sie verschwindet nicht. Auch 2 Leute können sich gegenseitig von Unsinn überzeugen. Trotzdem ist sicher die Denkfehlerzeit geringer im Twincoding. Der Vorteil wird allerdings meistens mit einem höheren Kommunikationsaufwand bezahlt, das sich 2 Leute über Modelle und Architekturen verständigen müssen. Der Aufwand ist nicht unerheblich, wenn die beiden nicht sehr kompatibel sind. Die dritte Fehlerzeitquelle sind Blockaden, wenn Detailprobleme den Fluss unterbrechen. Diese können von Tools, Fremdfehlern (z.B. Libraryfehler) oder Informationsdefiziten herrühren und unheimlich viel Zeit und Motivation kosten. Oft kann eine zweite Sichtweise und ein komplementäres Wissen den Konten viel schneller lösen.

Flüchtigkeitsfehler kosten nur wenige Sekunden oder Minuten. Denkfehler kosten zig Minuten oder Stunden, selten Tage. Blockaden kosten oft Stunden oder Tage. Bei allen Fehlerarten kann Twincoding deutlich helfen. Ich schätze, dass gute Programmierer, die Dinge programmieren von denen sie etwas verstehen, aber trotzdem nicht die Hälfte Ihrer Zeit mit Fehlern verbringen, die durch Twincoding vermieden worden wären. Denn ein Teil der Programmierzeit besteht aus Routinearbeiten und Tests, die sich nicht beschleunigen lassen . Ob Twincoding wirtschaftlich gerechtfertigt ist, hängt vom Einzelfall ab. Oft müssen Routinetätigkeiten ins Einzelcoding verschoben werden mit der Gefahr von geringem Synchronisationsverlust. Selbst für den Spezialfall von zwei guten und gut abgestimmten Programmierern kann man keine klare Aussage treffen aufgrund der Reduzierung von Fehlerzeit. Die Effizienz von Twincoding ist fraglich.

Entscheidend ist der Faktor Motivation. Zwei Programmierer lassen sich weniger ablenken. Sie fangen früher an und bleiben länger bei der Sache. Mit anderen Worten: sie lesen nicht morgens Onlinezeitung und 10 mal am Tag zwischendurch Email. Sie verlagern projektunabhängige Wartungstätigkeiten auf den Abend und lassen sich weniger von Zwischenrufen anderer Kollegen ablenken, weil man den Partner nicht gerne warten lässt. Gemeinsame Motivation kann Twincoding ins Plus schieben.

Trotzdem sind 150 Euro pro Team-Programmierstunde ziemlich viel. Wenn man die Kosten reduziert, dann geht Twincoding deutlich ins Plus. Wir ersetzen deshalb gerne einen der zwei Programmierer durch einen Aufpasser. Der Aufpasser muss nicht ein erfahrener Programmierer sein, sondern z.B. ein guter Praktikant. Der Aufpasser vermeidet genauso gut Flüchtigkeitsfehler. Er hat etwas weniger Einfluss auf Denkfehler und Blockaden. Ist der Aufpasser nicht beteiligt an der Architektur, dann kann er wenig helfen Denkfehler zu vermeiden. Andererseits hat der Leadprogrammierer die Chance bei Erklärungen die Denkfehler selbst zu entdecken. Der korrigierende Einfluss des Aufpassers auf Blockaden kann genauso gut sein, wie bei einem erfahrenen Programmierer. Der Aufpasser hat eher ein komplementäres Wissen, als ein langjähriger Kollege und kann deshalb manchmal besser sein, als der zweite Programmierer. Die Motivationsfunktion wird vom Aufpasser genauso gut ausgefüllt.

Zusammenfassend verliert Twincodig-Light wenig Performance gegenüber traditionellem Twincoding während die Kosten deutlich sinken.

_happy_coding_