Ich glaube es kaum, aber ich habe ein Buch über Software Engineering gelesen, das fast 10 Jahre vor meiner Geburt geschrieben wurde:

Das Buch stand schon recht lange auf meiner Leseliste, schliesslich ist es einer der Klassiker in seinem Bereich. Brooks schreibt von seinen Erfahrungen, die er bei der Entwicklung von OS/360 gemacht hat, einem 5000 Mannjahre / 50 Millionen $ Riesenprojekt.

Das Alter merkt man dem Buch schon an, das Lesen ist teilweise recht anstrengend, da man konstant überlegen muss, wie sich das Gelesene auf die heutigen Umstände portieren lässt. Im Buch werden beispielsweise reihenweise Betriebssysteme geschrieben, und das in nicht gerade komfortablen Sprachen. Andere Kapitel sind “zeitloser”, wie dasjenige, das dem Buch den Namen gegeben hat und welches schlussendlich zu Brooks’s law führte:

Adding manpower to a late software project makes it later

Warum? Für jeden neuen Mitarbeiter braucht es einen vorhandenen Mitarbeiter, der den Neuen einführt und wahrscheinlich auch häufig mit Fragen in seiner Arbeit unterbrochen wird. Ausserdem braucht es eine gewisse Zeit, bis der Neue richtig produktiv mitarbeiten kann. Auch steigt der Kommunikations- und Managementoverhead je mehr Leute an einem Projekt arbeiten. Eventuell muss sogar die ganze Planung angepasst werden, um die Arbeit besser auf mehr Leute zu verteilen (zumindest in einem weniger agilen Prozess). Man sollte also vorsichtig sein, einfach neue Leute in ein Projekt zu “werfen”.

No Silver Bullet

Ein weiteres, sehr spannendes und bekanntes Kapitel ist “No Silver Bullet”, welches auch heute noch zu Diskussionen führt. Um was geht es? Brooks behauptete, dass es in den nächsten Jahren keine “order of magnitude” Produktivitätssteigerung in der Software-Entwicklung mehr geben wird. Dazu muss man wissen, dass Brooks die Komplexität der Software-Entwicklung in zwei Komponenten zerlegt: die unbeabsichtigte und die essentielle. Unbeabsichtig ist alles, was man sozusagen als “Ballast” mitschleppt und tun muss, um die essentielle Komplexität einer Software zu erreichen. Essentielle Komplexität sind beispielsweise die Features, die der Kunde will, oder das Design und die Ueberlegungen, die man zum lösen des Problems anstellen muss. Mit neuen Entwicklungstools und Programmiersprachen lässt sich eigentlich nur die unbabsichtigte Komplexität reduzieren, und da dieser Teil mit der Zeit immer kleiner wurde, lässt sich die Gesamtkomplexität der Entwicklung immer schwerer reduzieren als zu der Zeit, als man noch Lochkarten stanzen oder Assemblercode schreiben musste.
Ich hoffe, ich habe das richtig verstanden und erklärt, ansonsten sollen mich Emanuel und Guido bitte korrigieren (die waren an einem OOPSLA-Workshop zu diesem Thema).

Was mir am Buch auch noch sehr gefallen hat sind die Zusatzkapitel, die in der Neuauflage hinzugekommen sind und sich mit den Reaktionen zum Buch auseinandersetzen, die einzelnen Bereiche nochmals analysieren um zu verstehen, was sich bewahrheitet oder wo sich Brooks geirrt hatte.

Die beiden erwähnten Kapitel sollte eigentlich jeder mal gelesen haben, die restlichen Themen lohnen sich wohl nicht so, bzw. gibt es bessere zeitgemässe Bücher.