The Mythical Man Month - Überblick über Kapitel 1 und 2

Michael Opitz
28. April 2009

debugged werden. Darüber hinaus muss Dokumen-

tation geschrieben werden und das Produkt muss
gewartet werden. Der Aufwand ein solches Projekt
zu erstellen ist daher ungefähr 3x so hoch wie bei
einem gewöhnlichen Programm.
Ein Programmier-System ist ein Programm, dass mit
externer Software über Schnittstellen kommunizieren
muss. Es müssen selber Schnittstellen definiert wer-
den um anderen Programmen zu ermöglichen mit
dem Programm zu kommunizieren. Eingabe- und
Ausgabe-Daten müssen genau validiert werden um
sicherzustellen dass sie mit der Spezifikation überein-
Abbildung 1: Zeitaufwand bei unterschiedlichen Pro- stimmen. Selbstverständlich muss gegen alle mögli-
grammtypen chen Komponenten ausführlich getestet werden, was
wiederum einen erhöhten Zeitaufwand von minde-
stens den Faktor 3 im Vergleich zu normalen Pro-
Zusammenfassung grammen darstellt.

The Mythical Man Month ist ein Buch von P. Brooks, in Ein Programmier-System Produkt ist sowohl ein
dem er seine Erfahrungen über Software Engineering, die Programmier-Produkt als auch ein Programmier-
er durch die Entwicklung von OS/360 bei IBM gewonnen System und hat daher einen mindestens 9x so hohen
hat, schildert. Im folgenden Artikel möchte ich einen klei- Zeitaufwand wie ein normales Programm.
nen Überblick über die ersten beiden Kapitel geben und
meine eigene Meinung einfließen lassen.
2 Kapitel 2
Kapitel 2 dreht sich um die im Buchtitel schon angespro-
1 Kapitel 1 chenen Mann-Monate. P. Brooks Hauptaussage in diesem
Kapitel 1 dreht sich zunächst um den Zeitaufwand bei Kapitel ist:
unterschiedlichen Programm-Typen (siehe Abbildung 1).
Adding manpower to a late software project ma-
kes it later.
Ein Programm ist eine Software, die nur auf einem
Rechner zum Einsatz kommt und wird nur auf die- Dies dadurch begründet, dass neues Personal erst ein-
sen einen Rechner entwickelt, debugged und getestet. geschult werden muss und nicht gleich mit 100%iger Pro-
Das Programm muss nicht mit externen Schnittstel- duktivität arbeiten kann. Außerdem steigt durch eine
len kommunizieren. Mehrzahl an Entwicklern der Kommunikationsaufwand
quadratisch an:
Ein Programmier-Produkt ist eine verkaufsreife
Software, die auch auf mehreren Rechnern läuft. Sie n ∗ (n − 1)
muss daher auf mehr Rechnern getestet werden und Kommunikationsauf wand = (1)
2

1
Abbildung 2: Zeitaufwand bei einem 12 Mann-Monate Abbildung 4: Das Verzögerte Projekt mit zusätzlichen
Projekt mit 3 Entwicklern Entwicklern
Abbildung 3: Das Verzögerte Software-Projekt
Darüber hinaus kann es natürlich auch möglich sein,
dass man manche Aufgaben nicht aufteilen kann, da man
sequentielle Abhängigkeiten zwischen einzelnen Kompo-
nenten hat.
Dazu gibt es auch ein illustratives Beispiel. Angenom-
men man hat ein Softwareprojekt mit 4 Milestones, das
12 Mann-Monate dauert und an dem 3 Entwickler arbei-
ten. Dann ist die geschätzte Entwicklungszeit 4 Monate
(siehe Abbildung 2).
Angenommen das Projekt ist nun am Anfang um einen
Monat zu spät, dann schaut das erwartete Projektende
wie in Abbildung 2 aus.
Muss das Projekt jetzt allerdings unbedingt in 4 Mona-
ten fertig werden, dann könnte man auf die Idee kommen
die restlichen 9 Mann-Monate mit insgesamt 5 Entwick-
lern bewältigen zu wollen. Damit wäre das Projekt rein
rechnerisch dann in 2 Monaten fertig. Allerdings müssen
die neuen Entwickler erst eingeschult werden, was einige
Zeit in Anspruch nehmen könnte (siehe Abbildung 2).
Nun könnte man wenn man im Monat 3 sich den Status
anschaut wiederum auf die Idee kommen weitere Entwick-
ler einzustellen, was sich allerdings nicht auf ein kürzeres
Projektende auswirken wird..
Es wird generell vorgeschlagen den Zeitplan zu
verändern, sodass aber keine weiteren Änderungen mehr
2
vorgenommen werden müssen oder gegebenenfalls Featu-
res zu streichen um das Projekt rechtzeitig mit geringe-
rem Funktionsumfang fertig zu stellen.
3 Meine Meinung
Zur Zeit der Entwicklung von OS/360 hatte IBM noch
nicht viele Erfahrungen mit Softwareentwicklung ge-
macht. An Programmiersprachen waren damals gerade
einmal COBOL, PL/I und FORTRAN in Mode. Durch
die großen Verspätungen von OS/360 machte sich Brooks
offenbar Gedanken was beim Entwicklungsprozess richtig
gemacht wurde und wo die Probleme lagen und verfasste
’The Mythical Man Month’.
Erkenntnisse wie ’lieber unwichtige Features entfernen
oder den Zeitplan ändern anstatt neue Entwickler einzu-
stellen’ findet man heutzutage in modernen Agilen Vorge-
hensmodellen wie etwa Scrum wieder, wo Anforderungen
schon im vorhinein priorisiert werden und abgearbeitet
werden, sodass man im Notfall immer ein mehr oder we-
niger funktionierendes Produkt mit den wichtigsten Fea-
tures hat.
Darüber hinaus ist es erstaunlich, dass schon Brooks
damals zum Schluss gekommen ist dass kleinere Teams
wesentlich effektiver arbeiten als größere Teams und dass
es scheinbar talentierte Entwickler gibt, die ungefähr 10x
so produktiv sind wie untalentierte Entwickler. Dies ent-
spricht ebenfalls dem heutigen Trend eher Entwicklungs-
Teams klein zu halten, da dies den Kommunikationsauf-
wand minimiert und so die Produktivität steigert (siehe
Formel 1).
Desweiteren hat er schon damals erkannt, dass es einige
wenige Architekten geben soll, die miteinander harmonie-
ren, sodass die Konsistenz des (User)- Interface gewahrt
ist. Dadurch ist das System insgesamt leichter zu durch-
schauen. Viele Architekten würden sehr unterschiedliche
Ideen liefern, was zu einem schwer zu durchschaubaren
(User)-Interface führen würde. Außerdem spricht er Ele-
mente wie Simplizität an, die im Design wichtig sind.
Diese Dinge sind heute noch im User-Interface-Design
sehr wichtig. Man muss sich nur erfolgreiche Projekte wie
zum Beispiel die Google Suche (bestehend aus einer sim-
plen einfachen Eingabebox mit Button) oder Apple’s iPod
(simpel, da wenige Tasten, konsistentes Interface, ...) an-
schauen.