90-90-Regel

Die 90-90-Regel (wörtlich von englisch ninety-ninety rule) ist ein Aphorismus aus der Softwareentwicklung. Er fasst verschiedene Phänomene der Programmierung von Software, insbesondere des Zeitmanagements während der Entwicklungsphase, humoristisch zusammen. Als Urheber der Regel gilt Tom Cargill von den Bell Laboratories. Bekannt wurde sie im Jahr 1985, als Jon Bentley sie in seiner Kolumne Programming pearls (etwa: „Programmierungs-Perlen“) des Communications of the ACM-Fachmagazins unter dem Titel Rule of Credibility („Regel der Glaubwürdigkeit“) zitierte. Sie lautet:

“The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.”

„Die ersten 90 Prozent des Codes benötigen die ersten 90 Prozent der Entwicklungsdauer. Die verbleibenden 10 Prozent des Codes benötigen die anderen 90 Prozent der Entwicklungsdauer.[1]“

– Tom Cargill, Bell Laboratories

Aussagen

Die 90-90-Regel erinnert im Wortlaut an das Paretoprinzip, ist aber im Gegensatz zu diesem nicht ganz ernst gemeint: die Tatsache, dass die prozentuale Summe der Entwicklungsdauer mehr als 100 % ergibt, ist eine Anspielung auf den Zeitverzug, der bei Softwareprojekten oft zu beobachten ist. Angesetzte Deadlines werden teils mehrmals nach hinten verschoben oder schlicht nicht eingehalten, weshalb sich die tatsächliche Entwicklungsdauer von Software oft deutlich länger (180 %) hinzieht als die ursprünglich geplante Zeitspanne (100 %).

Die Regel beschreibt ferner das fehlende Geschick, komplizierte Codestellen schon bei der Aufwandsschätzung zu identifizieren. Scheinen während der ersten 90 % der geplanten Projektdauer verstrichene Zeit und Menge des Codes noch zusammenzupassen, so zeigt sich während der Arbeit an den letzten 10 % des Codes, dass für diesen noch einmal genauso viel Zeit benötigt wird wie für die ersten 90 %, weil der Aufwand hierfür vollkommen unterschätzt wurde.

In der agilen Softwareentwicklung trifft die Regel oftmals auf Aufgaben zu, die als „nahezu fertig“ gelten. Dieser weit verbreitete Zustand deutet oftmals darauf hin, dass die geplante Arbeit zwar im Wesentlichen erledigt wurde, die Aufgabe aber nicht als abgeschlossen markiert werden kann, da sie noch auf eine andere Aktivität wartet. Deren Abschluss kann aber möglicherweise noch einen erheblichen Zeitraum auf sich warten lassen.

Quellen

  1. ↑ Jon Bentley: Programming pearls: Bumper-Sticker Computer Science. In: Communications of the ACM. Band 28, Nr. 9, 1985, ISSN 0001-0782, S. 896–901, doi:10.1145/4284.315122.