Ein kurzer Einblick in eine x-beliebige Programmiererbude:
Chef: Bis wann kann ich mit der ersten präsentablen Version rechnen?
Entwickler: Also wenn wir den Fehler X noch beheben, und das Layout anpassen sollen, und dann sind da noch die Probleme mit …
Chef: Ich brauche es bis spätestens Anfang Dezember!
Entwickler: Oh Chef, ich glaube das wird nichts. Das ist zu kurzfristig. Da ist dann nur so ne halbgare Sache.
Chef: Läufts bis dahin? Kann man es bedienen?
Entwickler: Ja!?
Chef: Na also. Der Rest ist doch unwichtig. Die paar Bugs, die bekommen wir auch noch raus.
Microsoft hat es endlich geschafft. Der erste Release Candidate ist draußen und die ganze Welt schielt gen Redmond. Bekommt die Microsoft-Crew das neue Betriebssystem rechtzeitig fertig? Und vor allem wann?
Prinzipiell interessiert dies niemand so genau. Denn Hauptsache man kann es runterladen, anschauen und testen. Und selbst wenn es irgenwann fertig sein sollte, zumindest wann Microsoft es für „final“ dekliniert, ist es den Benutzern relativ egal, ob es an manchen Ecken und Kanten noch nicht ganz fertig erscheint. Zum einen ist man von Microsoft nichts anderes gewohnt. Zum anderen ist der Druck aus der Industrie viel zu hoch, um sich noch weitere Verspätungen zu leisten.
Sicherlich wird Microsoft viel daran liegen, ein möglichst fehlerfreies System auf dem Markt zu bringen. Anderseits wird man es auch „unfertig“ auf den Markt werfen, wenn es einen gewissen Reifegrad erreicht hat. Die interne Updatefunktion macht es möglich.
Im Grunde geht es nicht darum, ob Microsoft rechtzeitig fertig wird. Wenn Steve Balmer das „Go!“ gibt, wird das Paket einfach auf den Markt geschmissen. Lieber ein Betriebssystem voller kleiner fieser Bugs als gar kein neues Windows.
Aber so ist das nun einmal in der freien Marktwirtschaft. Der Programmierer würde sich gern noch zwei Monate mehr Zeit geben, der Abteilungsleiter hingegen muss dem Druck aus der Konzernleitung klein bei geben. Und die „big Bosses“ stehen mit dem Rücken an der Wand, wenn es um Zeitverschiebungen im Releaseplan geht.
Das Problem dabei ist das nach dem fixen von x Bugs in Iteration n immer log(x)^n Bugs in Iteration n+1 neu erscheinen. Und sollten mal weniger Bugs gefunden werden, so werden diese durch „absolut sinnvolle“ Feature oder Change Requests ersetzt.