Irgendwann wurde dieses Buch irgendwo empfohlen. Ich habe es angeschafft und eigentlich ein paar amüsante Essays über Fehleinschätzungen bei Programmierprojekten erwartet. Mir war dabei nicht klar, dass dieses Buch aus dem Jahr 1975 ist.
Ich habe immerhin die erweiterte 20 Jahre Jubiläumsausgabe von 1995, die um ein paar Kapitel erweitert wurde, aber alle alten Kapitel wurden unverändert gedruckt. Die meiste Erfahrung von Brooks kommt von seiner leitenden Rolle bei der Entwicklung des IBM OS/360 (vorgestellt noch früher, nämlich 1964), und darum geht es auch hauptsächlich im Buch.
Und Leute, es war vielleicht noch nicht klar, aber 1975 ist so lange her, wenn es um Computer geht! 1975 gab es quasi keine Personal Computers, keine E-Mails (im Buch wird immer wieder empfohlen, man solle mit seinen Kollegen telefonieren!), keine Webseiten (im Buch gibt es eine Stelle, wo er beschreibt, dass das Handbuch während der Entwicklung des OS/360 mehrere Fuß breit war und sie irgendwann auf Mikrofilm umgestiegen sind, weil sonst jemand jeden Tag 150 neue Seiten Dokumentation einheften musste!), strukturiertes Programmieren mit Loops statt GOTO war noch umstritten, C war gerade brandneu (wurde aber im Buch nicht erwähnt). An einer Stelle erzählt er, wie sie durch schlechte Nutzung von Systemressourcen einen Compiler hatten, der fünf FORTRAN-Statements pro Minute kompiliert hat. ALTER.
Irgendwann habe ich mich damit abgefunden, dass das Buch eher ein historisches Dokument ist als etwas, das ich in meinem täglichen Leben anwenden kann – und von da an ging es eigentlich. Klar, ein paar Sachen kann man bestimmt mitnehmen oder hat man schon irgendwoanders gehört, aber als „modernen“ Überblick über Softwareentwicklung würde ich es nicht empfehlen.
Sidebar: Ja, ich weiß, es handelt sich hier literally um einen alten weißen Mann, aber ich schwöre, in diesem Buch kommt keine einzige Frau vor, außer, in der Widmung, seine Ehefrau Nancy. Alle Teams bestehen aus Männern, alle Chefs sind Männer, die Architekten sind Männer, einfach alle Arbeitskräfte sind Männer, die Mann-Tage und Mann-Monate und Mann-Jahre an Arbeit in etwas reinstecken.
Irgendwann wurde dieses Buch irgendwo empfohlen. Ich habe es angeschafft und eigentlich ein paar amüsante Essays über Fehleinschätzungen bei Programmierprojekten erwartet. Mir war dabei nicht klar, dass dieses Buch aus dem Jahr 1975 ist.
Ich habe immerhin die erweiterte 20 Jahre Jubiläumsausgabe von 1995, die um ein paar Kapitel erweitert wurde, aber alle alten Kapitel wurden unverändert gedruckt. Die meiste Erfahrung von Brooks kommt von seiner leitenden Rolle bei der Entwicklung des IBM OS/360 (vorgestellt noch früher, nämlich 1964), und darum geht es auch hauptsächlich im Buch.
Und Leute, es war vielleicht noch nicht klar, aber 1975 ist so lange her, wenn es um Computer geht! 1975 gab es quasi keine Personal Computers, keine E-Mails (im Buch wird immer wieder empfohlen, man solle mit seinen Kollegen telefonieren!), keine Webseiten (im Buch gibt es eine Stelle, wo er beschreibt, dass das Handbuch während der Entwicklung des OS/360 mehrere Fuß breit war und sie irgendwann auf Mikrofilm umgestiegen sind, weil sonst jemand jeden Tag 150 neue Seiten Dokumentation einheften musste!), strukturiertes Programmieren mit Loops statt GOTO war noch umstritten, C war gerade brandneu (wurde aber im Buch nicht erwähnt). An einer Stelle erzählt er, wie sie durch schlechte Nutzung von Systemressourcen einen Compiler hatten, der fünf FORTRAN-Statements pro Minute kompiliert hat. ALTER.
Irgendwann habe ich mich damit abgefunden, dass das Buch eher ein historisches Dokument ist als etwas, das ich in meinem täglichen Leben anwenden kann – und von da an ging es eigentlich. Klar, ein paar Sachen kann man bestimmt mitnehmen oder hat man schon irgendwoanders gehört, aber als „modernen“ Überblick über Softwareentwicklung würde ich es nicht empfehlen.
Sidebar: Ja, ich weiß, es handelt sich hier literally um einen alten weißen Mann, aber ich schwöre, in diesem Buch kommt keine einzige Frau vor, außer, in der Widmung, seine Ehefrau Nancy. Alle Teams bestehen aus Männern, alle Chefs sind Männer, die Architekten sind Männer, einfach alle Arbeitskräfte sind Männer, die Mann-Tage und Mann-Monate und Mann-Jahre an Arbeit in etwas reinstecken.