In seinem Buch „Psychology of Computer Programming“ schreibt Gerald Weinberg 1971 über verschiedene Untersuchungung zur optimalen Länge der Turnaround-Zeit, also die Zeit die vergeht zwischen der durchgeführten Programm-Änderung und dem Feedback das der Programmierer über die Auswirkungen erhält. In jenen Tagen meinte das die Zeit zwischen der Abgabe des Lochkarten-Stapels beim mainframe-Operator und der Abholung des Ausdrucks mit dem Ergebnis.
Allein die Tatsache, daß die Untersuchungen kein einheitliches Ergebnisse erbrachten muß den Programmierer von heute überraschen. Warum sollte man etwas anderes erwarten als den Wunsch nach unmittelbarem Feedback? Tatsächlich gab es schon damals Manager, die genau diese Erwartung hatten. Eine Befragung brachte das erstaunliche Ergebnis, daß ein Durchschnittlicher Tunaround von 31 Minuten als zu kurz empfunden wurde. Was soll man davon halten?
Ergänzend dazu sollte vielleicht erwähnt werden, daß in jener Zeit die Time-Sharing-Systeme aufkamen, die es dem Entwickler ermöglichten die Programm-Aufträge direkt am Terminal aufzugeben und das Ergebnis abzuwarten. Anders als heute waren sich die Entwickler erstaunlicherweise noch nicht einig, ob das Dialog- dem Batch-System vorzuziehen sei.
Unvorstellbare Ansichten? Wer heute einen Computer befragt, erwartet Antwort in Echtzeit, möglichst ohne erkennbaren Verzug — schließlich will man so schnell wir möglich weiterarbeiten. Aber es wäre doch absurd annehmen zu wollen, daß der Batch-Entwickler nach Abgabe seines Lochkartenstapels die halbe Stunde däumchendrehend auf seine Kaffeetasse gestarrt hätte. Nein,, er hat vielmehr die Wartezeit damit genutzt über sein Programm nachzudenken, die nächsten Schritte zu planen, das Ziel des nächsten Probelaufs vorzubereiten. Die Auszeit gab Gelegenheit die Augen vom unmittelbaren Problem zu lösen und den Blick über die gesamte Aufgabe schweifen zu lassen.
Die lange Wartezeit erhöhte aber auch die Wertschätzung des Entwicklers für den Testlauf. Um diesen nicht durch einen Flüchtigkeitsfehler zu unbrauchbar zu machen, haben die Entwickler mehr Sorgfalt auf die Programmierung verwandt. Wir sind heute gewöhnt, daß uns die IDE unsere Syntax-Fehler beim Eintippen sofort um die Ohren haut. Wer zwischendurch auch mal mit dem klassischen Edit – compile – run – Zyklus arbeitet, kennt den Unterschied.
Was können wir davon für die heutige Entwicklungsarbeit mitnehmen? Wartezeit ist keine verlorene Zeit wenn man sich nutzt. Schrumpft die Turnaround-Zeit auf Sekundenbruchteile zusammen läßt sie sich nicht mehr nutzen, ist also tatsächlich verloren. Der geneigte Leser mag selbst mal zusammenrechnen — und darüber staunen — was ihm da über den Tag verloren geht.
Und auch an die Wertschätzung sollten wir im immer schneller rotierenden Wirbel des TDD-Zyklus denken. Je kleiner die Änderungen im Zyklus werden, desto größer wird die Gefahr daß der Entwickler den Blick für das Gesamtproblem verliert. Das klingt abstrakt und paranoid; es soll auch nicht bedeuten, daß jeder Entwickler zwangsläufig in solchen Arbeitsstil verfällt. Ich möchte es verstanden wissen als Einladung sich selbst beim Arbeiten zuzuschauen und mal zu reflektieren, welche Auswirkungen die Arbeitsweise hat.
Ich stecke während der Leerlaufzeiten immer gern den Kopf aus dem Maschinenraum. Ist die turnarount-Zeit zu lang, kommt das Boot nicht vorwärts. Ist sie zu kurz, wird es vom Kurs abkommen.