Buch-Rezension zu "The Mythical Man-Month"

"The Mythical Man-Month: Essays on Software Engineering" von Frederick Brooks erschien erstmals 1975. Das Buch war so erfolgreich, dass man 1995 zum 20. Geburtstag eine Jubiläumsausgabe auflegte.

Ich hörte im Studium zum ersten Mal von diesem Buch. Sofern ich mich richtig erinnere hatten wir in Aspekte der Wirtschaftsinformatik die Grundthesen besprochen. Nun war es an der Zeit, das ganze Buch zu lesen.

"The Mythical Man-Month" ist eines von 14 Essays der Erstausgabe. Die mir vorliegende Jubiläumsausgabe beinhalten darüber hinaus auch das bekannte Essay "No Silver Bullet" sowie 3 weitere Kapitel.

Ein Blick in die Vergangenheit

Vor 35 Jahren sah die IT-Welt komplett anders aus. Computer waren noch riesig und Rechenzeit teuer. Entsprechend gross waren die Unterschiede bei der Software-Entwicklung. Mal eben schnell kompilieren und schauen ob man einen Fehler im Syntax hat war unvorstellbar - die Rechenzeit war dafür viel zu kostbar.

Die weniger bekannten Essays liefern einem einen interessanten Einblick in die damalige Zeit. Die technischen Probleme die damals die Entwickler beschäftigte sind heute kaum mehr vorstellbar. Der Fortschritt bei den Computern und der damit einhergehende Zerfall der Preise macht viele der empfohlene Lösungsansätze überflüssig.

Bei den organisatorischen Problemen sieht die Sache anders aus. Da Software immer noch von Menschen geschrieben wird, sind die Probleme auch heute noch aktuell. Ein Blick auf die Erfahrungen bei den organisatorischen Problemen lohnt sich somit noch immer.

The Mythical Man-Month

Ist ein Projekt im Verzug, wird in der Regel immer eine Massnahme getroffen: Man setzt mehr Leute ein. Und häufig ist das Resultat eine noch grössere Verzögerung. Brooks versucht in seinem Essay die Ursache dafür aufzuzeigen.

Eines der grundlegenden Probleme ist ein falsches Verständnis von Mannmonaten (oder heutzutage Personenmonate). Wenn 1 Person für eine Tätigkeit 5 Monate benötigt, können 5 Personen diese nicht automatisch in 1 Monat erledigen. Die Austauschbarkeit von Personen und Monate ist nur dann Möglich, wenn die Tätigkeit sich in unabhängige Untertätigkeiten aufteilen lässt. Sobald die Arbeiten aber eine Sequenz von Abläufen beinhalten, kann man nicht mehr Parallelisieren. Man kann immer mehr Leute an die Aufgabe setzen, doch wenn diese nur auf den Abschluss einer vorgehenden Tätigkeit warten, gewinnt man keine Zeit.

Am Tech wurde uns das anhand von einem Beispiel aus dem Buch erläutert, das in etwa so lautet: Eine Schwangerschaft dauert 9 Monate. Nur weil 2 schwangere Frauen in 9 Monaten 2 Kinder zur Welt bringen, ist das erste Kind dennoch nicht nach 4.5 Monaten "fertig".

Ein weiterer nicht zu unterschätzender Punkt ist die Kommunikation. Je mehr Leute an einer Aufgabe sind, desto mehr muss kommuniziert werden. Die Formel zum Berechnen der Kommunikationswege ist n(n − 1) / 2, wobei n die Anzahl Personen ist. Danach benötigen 3 Personen schon 3 mal mehr Kommunikationswege als 2 Personen, bei 4 Personen sind es schon 6 mal mehr.

Mehr Aufwand für Kommunikation und Tätigkeiten die nicht parallelisiert werden können führen schnell zur oft beobachteten Verlangsamung. Brooks Fazit lautet daher, dass wenn man einem verspäteten Projekt gegen Projektende mehr Leute hinzufügt, es erst recht zu Verspätungen kommt. Will man dies Verhindern, muss man frühzeitig eingreifen. Oder man lässt die ursprüngliche Gruppe weiterarbeiten und akzeptiert die Verspätung. Die ist am Ende oft sogar deutlich kleiner, als wenn man gegen Ende mehr Leute hinzufügt.

No Silver Bullet

Wäre es nicht toll, gäbe es für jedes Problem eine Lösung, mit der man die gleiche Arbeit in einem Bruchteil der Zeit und der Kosten erledigen könnte? Diese silberne Kugel die das Ungeheuer der Komplexität vertreibt war schon 1986 das Thema von einem weiteren bekannten Essay von Brooks. Nur gibt es solche Kugeln nicht.

Software ist insofern ein spezielles Gut, als das es nicht einfach während einer definierten Zeit erzeugt und dann nur noch verwendet wird. Ein Auto als Beispiel wird im Werk gefertigt und fährt dann bis zu seiner Verschrottung praktisch unverändert herum. Es käme niemand auf die Idee, aus einem PKW einen Lastwagen zu machen. Bei Software sieht dies anders aus. Da wird hier noch ergänzt, da kommen neue Anforderungen und dann könnte es doch dies auch noch gleich machen. All dies erhöht die Komplexität und macht die Beschleunigung um Faktoren (und nicht nur Prozente) unmöglich.

Aber die silberne Kugel ist verlockend. Brooks beschreibt Objektorientierte Programmierung, Künstliche Intelligenz, Expertensysteme, grafische Programmierung und noch vieles mehr, das zu seiner Zeit als solche silberne Kugel galt. Heute wäre die Liste stellenweise anders, doch wie vor fast 25 Jahren geht es auch heute nur noch einige wenige Jahre bis dies funktionieren soll.

Die Veränderungen um Faktoren werden gemäss Brooks kommen, allerdings durch andere Anforderungen. Ein Kunde der 2 Mio. $ für Hardware ausgab, war durchaus bereit nochmals 250'000$ für ein auf seine und die Bedürfnisse der Hardware optimierte Lohnabrechnung zu kaufen. Kostet ihn die gleiche Hardware aber nur noch 50'000$ wird er sicher nicht das 5 fache für ein eigenes Programm ausgeben. Stattdessen wird ein Standardprodukt gekauft und man passt seine Abläufe der Software an. Dadurch reduzieren sich die Sonderfälle und Eigenheiten, was wiederum tiefere Kosten bringt.

Wann immer einem jemand ein Produkt als Lösung für alle Probleme verkaufen will, sollte man daher wachsam sein. Viele der zu lösenden Probleme kamen erst durch die letzte Lösung, die einem alle Probleme lösen sollte...

Fazit

In der Jubiläumsausgabe ist auch ein Rückblick von Brooks enthalten. Neben einem Blick auf die letzten 20 Jahre listet er auch auf, was er selber für überholt hält. Da dies viele der weniger bekannten Essays in diesem Buch betrifft, sollte man dieses Kapitel möglichst zu Beginn lesen. Überholt bedeutet allerdings nicht, dass diese nicht gelesen werden sollen. Sie liefern einen sehr interessanten Einblick in eine vergangene Zeit.

Wie immer gilt auch bei diesem Buch, dass man sich seine eigene Meinung zu den Ideen des Autors machen muss. Das Buch ist mittlerweile 35 Jahre alt und das merkt man deutlich. Das muss einem bewusst sein, wenn man dieses Buch liest. Es gibt auch in den überholten Kapiteln zahlreiche gute Ideen, die es wert sind, darüber nachzudenken.

Das Essay "The Mythical Man-Month" hat für mich auch heute noch seine Berechtigung. Die Erkenntnisse sind ja nun wirklich nicht mehr neu, doch noch immer wiederholt man die gleichen Fehler - auch ausserhalb der IT.

Zum Buch

"The Mythical Man-Month: Essays on Software Engineering" von Frederick P. Brooks Jr, 1975 (original), 1995 Jubiläumsausgabe bei Addison Wesley, ISBN 978-0-201-83595-3, 336 Seiten