Windows ConfidentialWer zuletzt etwas ändert, hat verloren

Raymond Chen

Wenn ein Projekt vor dem Abschluss steht, spielt das Team oft das informelle Spiel „Wer zuletzt etwas ändert, hat verloren“. In diesem Spiel „konkurrieren“ Teams darum zu vermeiden, für die letzte Änderung am Produkt verantwortlich zu sein. Denn theoretisch hätte das Projekt einen Tag früher abgeschlossen werden können, wenn dieser Fehler nicht gefunden worden wäre. (Das ist zwar nur selten wirklich der Fall, stellt aber dennoch die Motivation für das Spiel dar.) Der Wettbewerb ist rein virtuell – keiner verfolgt den Spielstand, und der „Verlierer“ gerät schnell in Vergessenheit.

Es sei denn, Sie sind der Verlierer.

Einer der erfahrenen Mitarbeiter im Windows-Team gab mir gegenüber zu, das Spiel in den Anfangszeiten von Windows zwei Mal in Folge verloren zu haben. Das zweite Mal blieb besonders in Erinnerung, weil die Änderung vorgenommen wurde, nachdem die Produktion bereits begonnen hatte. Der gesamte Produktionslauf musste zurückgerufen und neu gestartet werden.

Der Versuch, noch eine dritte Niederlage einzufahren, wurde jedoch vereitelt. Beim dritten Versuch war es die vorletzte Änderung statt der letzten. Die letzte Änderung wurde von einem anderen Kollegen durchgeführt, der nicht nur die letzte Änderung bei Windows 2000, sondern auch bei Windows XP vornahm.

Es ist die Ironie des Spiels, dass häufig die Person verliert, die besonders kompetent ist (und von der man es daher am wenigsten erwarten würde). Es liegt also nicht daran, dass der Code nicht in Ordnung ist. Dank ihrer guten Vorbereitung sind sie in einer viel besseren Position, diese letzte Änderung vorzunehmen, selbst wenn sie für diese Komponente normalerweise nicht verantwortlich sind.

Eine späte Änderung ist mit großen Anstrengungen verbunden, da die Isolierung, die den Entwickler normalerweise von der Hauptstruktur trennt, nicht mehr vorhanden ist. Unter normalen Umständen läuft eine späte Änderung folgendermaßen ab:

• Sie melden sich in Ihrem Unterprojekt an.
• Die Buildtestumgebung Ihres Unterprojekts verarbeitet über Nacht die Änderung und liefert am Morgen einen Build.
• Das Testteam Ihres Unterprojekts studiert den Code eine Woche oder länger eingehend, bevor das OK gegeben wird, dass die Änderung an die Hauptstruktur übergeben werden kann.

Auf diese Weise ist es viel wahrscheinlicher, dass eventuell aufgetretene Fehler im Vorfeld erkannt werden und somit nicht offizieller Teil des Projekts werden. Einige Unterprojekte sind so groß, dass dieses Prinzip rekursiv angewendet wird. Das heißt, es werden dem Unterprojekt untergeordnete Projekte erstellt, deren Änderungen vor der Veröffentlichung an das größere Unterprojekt, zu dem sie gehören, unabhängig von einander geprüft werden.

Wenn Sie jedoch in der Endphase des Projekts sind, und das Releaseverwaltungsteam entscheidet, Ihre Problembehebung anzunehmen, ist die Zeit knapp, und mehrwöchige Änderungsüberprüfungsprozesse können nicht durchgeführt werden. An dem Projekt arbeiten viele Entwickler an verschiedenen Standorten, die regelmäßig am gesamten Projekt mitwirken (und nicht nur an ihrem Unterprojekt) – von der Bereinigung bis hin zum Erstellen von Datenträgerbildern auf einem internen Veröffentlichungsserver und dem Bestätigen der Übereinstimmung mit den Buildanforderungen. (So wird z. B. geprüft, dass das CD-Abbild für die CD nicht zu groß ist!)

Ist ein Team in der Situation, dass eine Änderung in letzter Minute vorgenommen werden muss, ist normalerweise der Mitarbeiter zuständig, der besonders gut vorbereitet ist – gibt es diese Person nicht, wird jemand aus einem benachbarten Team ernannt, der gut vorbereitet ist.

Nun beginnt das Spiel. Das Team bietet dem gut vorbereiteten Entwickler die Änderung an, und der Entwickler erstellt die Datenträgerabbilder, überprüft die Buildanforderungen und verweist das Testteam dann auf den internen Veröffentlichungsserver. Stellt das Testteam ein Problem fest, erstellt das Entwicklungsteam eine neue Problembehebung und gibt sie an den gut vorbereiteten Entwickler weiter, der den Kreislauf von neuem beginnt.

Anders gesagt, fungiert der gut vorbereitete Entwickler als virtuelle Ein-Mann-Buildtestumgebung für dieses Team. Wenn alle zufrieden sind, nimmt der gut vorbereitete Entwickler die Änderung vor. Deshalb sind es die gut Vorbereiteten, die beim Spiel „Wer zuletzt etwas ändert, hat verloren“ den Kürzeren ziehen. Es liegt nicht daran, dass sie für das Problem verantwortlich sind, sondern daran, dass sie den Verantwortlichen helfen können.

Raymond Chen befasst sich auf seiner Website The Old New Thing und in seinem gleichnamigen Buch (Addison-Wesley, 2007) mit der Geschichte von Windows, mit der Win32-Programmierung und mit explodierenden Kaffeemaschinen.