In diesem klassischen Buch über den Softwareentwicklungsprozess zerstört Fred Brooks mehrere hartnäckige Mythen. Sie verschwinden nie ganz: Jede neue Generation muss sie nur noch einmal lernen.

Der erste und gefährlichste dieser Mythen ist der Glaube, dass mehr Leute an einem Projekt beteiligt sind, was bedeutet, dass es schneller abgeschlossen wird. Brooks enthält eine der brillantesten Grafiken, die ich je gesehen habe. Sie zeigt die Anzahl der Frauen gegen die Zeit, die für die Geburt eines Babys erforderlich ist. Würden Sie es glauben: Die Grafik ist nach neun Monaten flach, unabhängig davon, wie viele Frauen dem Projekt zugeordnet sind. Wie er betont, ist die Softwareentwicklung oft bemerkenswert ähnlich.

Wenn Sie ein junger Softwareentwickler sind und von den oben genannten Punkten überhaupt überrascht waren, sollten Sie sich unverzüglich eine Kopie von Brooks besorgen. Einige seiner Beobachtungen mögen jetzt etwas veraltet sein, aber das meiste davon ist immer noch verdammt relevant.

Soweit ich das beurteilen kann, sind die Grundprinzipien dieses Buches nicht mehr wirklich umstritten. Ich will nicht wie der mürrische Leser klingen, der im Nachwort erwähnt wird und sich darüber beschwert, dass das Buch "nichts bietet, was ich noch nicht wusste" (wie erfahren er auch gewesen sein mag, ich bezweifle es immer noch), aber ob von meinem begrenzten Erfahrung in der Branche aus erster Hand oder aus zweiter Hand durch die verschiedenen Manager, die ich im Laufe der Jahre hatte. Der Grundsatz, dass Entwickler und Zeit keine austauschbaren Ressourcen sind, fühlte sich sowohl vertraut als auch selbstverständlich an. In gewissem Sinne habe ich nicht das Gefühl, dass ich mehr geschäftliche Kritik an diesem Buch habe als "Relativitätstheorie: Die spezielle und allgemeine Theorie". Ein weiterer Teil meines Gehirns ist zufrieden damit, eine Kritik des Buches zu trennen qua Buch von jeder Art von Streit mit den tatsächlichen Argumenten und teilen Sie einige kleine Schnipsel, die diese Lesung weniger angenehm machten, als es hätte sein können:

1) Seine hartnäckige Weigerung, jemals die Realität weiblicher Programmierer anzuerkennen.

Dieser frustrierende Trend beginnt mit dem Titel (was zum Teufel ist ein "Mann" -Monat? Braucht Ihr Projekt Bärte, um zu wachsen, oder Code, um geschrieben zu werden?) Und einfach nie. Lasst uns. Oben. Abgesehen von einem grammatikalisch notwendigen "sie" bei der Erwähnung von Frances Spence (auf der letzten Seite!) Bin ich mir nicht sicher, ob weibliche Pronomen in diesem gesamten Buch einmal vorkommen. Sicher, "sie" hatten damals nicht die gleiche Legitimität wie ein geschlechtsneutrales Singularpronomen wie heute, aber dieses Ding wurde 1995 neu aufgelegt, als "sie" vielleicht auf dem neuesten Stand waren, aber "er oder sie" "war schon in der Grundschule Standard. Es sind nicht nur Entwickler - Systemarchitekten, Manager, alle im "Operationsteam"; Zur Hölle, sogar BENUTZER, zumindest diejenigen mit einer gewissen Initiative beim Testen der Grenzen der Software, sind standardmäßig alle männlich.

Warten Sie, ich erinnerte mich nur - Frauen kommen. Um es mit anderen Worten zu sagen: "Sie können nicht neun Frauen schwanger machen und in einem Monat ein Baby erwarten."

Ugh.

Ich bin sicher, dass dies kein neuer Punkt ist, und ich bin sicher, dass er mit Anmut und Offenheit darauf reagiert hat, wie der Standard des Schreibens, den er mit gebrauchten männlichen Pronomen aufgewachsen ist, um sich auf JEDEN zu beziehen, und natürlich ist er es hatte das Vergnügen, im Laufe der Jahre mit vielen kompetenten, sogar visionären Frauen zusammenzuarbeiten, und so und so und so. Wenn es ein unschuldiges Versehen von Brooks war, den Originaltext ein wenig geschlechtsspezifisch zu gestalten, erhält sein Redakteur für die Neuauflage weniger Freikarte. Frauencode. Bitte aktualisieren Sie Ihre Grammatik.

2) Die unbegründeten religiösen Obertöne

Versteh mich nicht falsch - ich erinnere mich noch lebhaft an die fast spirituelle Ekstase dieses ersten Tages, als ich wirklich eine Rekursion "bekam", und ich verstehe vollkommen, wie jemand die Schönheit des Software-Designs in seinem bestehenden Rahmen der Spiritualität, dem Christentum, positionieren könnte. Leider ist eine Konsequenz des Aufbaus Ihrer gesamten Kosmologie um ein Wesen wie den westlichen monotheistischen Gott, dass es notwendigerweise alles und jeden anderen verbraucht; es wird dann fast unmöglich, über die Schönheit oder den Adel eines Strebens oder Prinzips zu schreiben, außer in dem Maße, in dem es angeblich ausstrahlt ab die Natur dieser vermeintlichen Entität. Eine Verbindung zwischen gutem Software-Design und christlichen Vorstellungen von Heiligkeit taucht immer wieder auf, und sie reizen mich nicht nur, weil sie ein bisschen scheinheilig wirken, sondern weil die christliche Linse oft tatsächlich den Inhalt verzerrt.

Zwei Beispiele fallen mir ein: Das erste kommt aus dem Kapitel "Aristokratie, Demokratie und Systemdesign", in dem die konzeptionelle Integrität als höchste Tugend eines Softwaresystems bezeichnet wird. Ich gebe zu, dass das Buch älter ist als alle Fortschritte, die echte Open-Source-Systeme oder die Errungenschaft von GNU / Linux möglich gemacht haben, um zu beweisen, dass es ein tragfähiges Modell war, aber Brooks scheint so in die Analogie der gottähnlichen Software verwickelt zu sein Architekt, dass er dem heidnischen "Basar" -Modell niemals faire Beachtung schenkt - die "Kathedrale" ist selbstverständlich jedem überlegen, der aufrichtig glaubt, dass die ganze Welt ein einheitliches, absichtliches Design einer einzigen Einheit darstellt.

Der zweite ist im Kapitel "Warum ist der Turm von Babel gescheitert?", Und mein Einwand läuft darauf hinaus: Der Turm von Babel ist nicht gescheitert, weil den Bauherren "Organisation und Kommunikation fehlten". Es ist gescheitert, weil ein Allmächtiger eingegriffen hat, um es zu schaffen unmöglich Organisation und Kommunikation zu haben; Dies geschah wiederum, weil der christliche Gott (und insbesondere der alttestamentliche Gott) ein wütendes, boshaftes und manchmal geradezu kleinliches Wesen ist und das organisierte menschliche Unternehmen, diesen Turm zu bauen, eine Herausforderung für seine Autorität darstellte. Die Interpretation, die Brooks gewählt hat, verwirrt mit nahen und endgültigen Ursachen, was es mir schwer machte, irgendetwas von dem zu kaufen, was folgte, egal wie legitim die Punkte selbst gewesen sein mögen.

Da das, was ich über Programmierung weiß, wahrscheinlich auf die Rückseite einer Postkarte geschrieben werden könnte und nicht lesenswert wäre, kann ich nichts über die Software-Engineering-Seite dieser Sammlung von Aufsätzen über Software-Engineering sagen.

Weitere Brooks schrieb in den 60er Jahren, teilweise basierend auf Erfahrungen aus den 50er Jahren, was bedeutet, dass ich einen Anspruch auf eine breitere Anwendbarkeit in Bezug auf Projektmanagement und Personalmanagement erheben und die Art der Aufgaben verstehen werde.

Ich habe die 20-jährige Jubiläumsausgabe gelesen, an die ich mich als nicht billig erinnere, und um den Preis zu rechtfertigen, ist sie mit vielen Schwarz-Weiß-Bildern von prähistorischen Tieren, die in einer Teergrube gefangen wurden, dem Turm von Babel, Werwölfen und anderen solchen Dingen, die springen, weitläufig angelegt Als Metaphern zur Erklärung der Erfahrungen bestimmter Projekte gibt es keinen brennenden Zeppelin, aber vielleicht wird dies in einer zukünftigen Ausgabe korrigiert.

Ich werde mit kurzen Zusammenfassungen der Aufsätze fortfahren:
Die Teergrube ?
Der Monat des mythischen Mannes - Wenn sich ein Projekt verspätet, verzögert sich das Hinzufügen zusätzlicher Arbeitskräfte nur weiter, insbesondere wenn die Art des Projekts die Kommunikation zwischen den Teammitgliedern erfordert.
Das Operationsteam Ein Projektteam ist am besten mit festen und exklusiven Rollen organisiert, wobei sich jedes Mitglied auf eine Aufgabe konzentriert. Wie ein Operationsteam ist dieser Ansatz skalierbar, wenn ein großes Projekt in geeignete Teile zerlegt werden kann
Aristokratie, Demokratie und Systemdesign Seien Sie wie die Kathedralenbauer von Reims und akzeptieren Sie die Kreativität, die Vision eines anderen umzusetzen, um über alle Harmonien hinweg das Beste zu erreichen
Der zweite SystemeffektDesigner ihres ersten Systems werden sich wohlfühlen, und so vorsichtig und schlank, dass ihr zweites System dann eher mit barocken Details und Haustierideen gefüllt ist.
das Wort weitergeben Ich denke, das war Projektdokumentation
Warum ist der Turm von Babel gefallen?Kommunikationsprobleme ärgern Gott auch nicht unnötig.
Calling the Shot ?
zehn Pfund in einem fünf Pfund Sack ?
Die dokumentarische Hypothese
planen, einen wegzuwerfen mehr oder weniger was es sagt
scharfe Werkzeuge meh, Computerzeug, diese Dinge werden sich nie durchsetzen.
das Ganze und die Teile wie oben und geh von meinem Rasen
eine Katastrophe ausbrüten "Wie kommt es, dass ein Projekt ein Jahr zu spät kommt? ... einen Tag nach dem anderen"(P.246)
das andere Gesicht ?
keine Silberkugel Gute Nachrichten für Werwölfe, es gibt keine Silberkugeln.

Dann werden die Hauptpunkte in kurzen Seiten 230-250 wiederholt, wodurch die Notwendigkeit für den Rest des Buches entfällt.

Ich hatte beim ersten Lesen ein paar Seiten im Kapitel No Silver Bullet gelesen, aber es war eine andere Person, die es las, und ich konnte mir nicht vorstellen, was seine Aufmerksamkeit damals erregt hatte. Ich bin anscheinend für mich tot (Spoiler anzeigen)[Das ist wahrscheinlich das Beste, weißt du, dieser Schädel ist nicht groß genug für uns beide und all das (Spoiler verstecken)]!

Das oben Gesagte klingt möglicherweise ziemlich widerwillig, insbesondere die Kapitel, die zu vapid schienen, um mehr als ein Fragezeichen zu verdienen. Dennoch fand ich dieses Buch beim ersten Mal sehr aufregend (und nicht nur wegen des Bildes der prähistorischen Megafauna, die in einer Plane gefangen wurde (Spoiler anzeigen)[obwohl der Einfluss davon auf mein fantasievolles Verständnis der Projektarbeit nicht zu unterschätzen ist (Spoiler verstecken)]). Dafür gibt es zwei Gründe. Zuerst. Wie er anerkennt, handelt es sich um ein Buch über Softwareprogrammierung, und daher geht es darum, dass Menschen in Teams arbeiten, um ein Serviceprodukt für Endbenutzer bereitzustellen, und er war zufällig mit Software vertraut, aber mein zweiter Grund ist, dass dies ein Weisheitsbuch ist und Diese Weisheit ist weit verbreitet - jede Organisation, die ein Produkt oder eine Dienstleistung an Endbenutzer liefert (die möglicherweise die zahlenden Personen sind oder nicht). Der Nachteil eines Weisheitstextes ist eindeutig, dass er apokryphisch ist (Spoiler anzeigen)[dh anekdotisch und abgeleitet (Spoiler verstecken)] aber ich bin alt genug und hässlich genug, um damit zu leben, tatsächlich fand ich es ebenso wie die Weisheitsliteratur ebenso beruhigend wie lehrreich. Ich hatte bemerkt, dass das Hinzufügen von Personen zum späten Projekt die Lieferung nicht schneller beschleunigt als das Hinzufügen zusätzlicher Frauen, um bei einer Schwangerschaft zu helfen, aber ich hätte es nicht gewagt zuzugeben, dass dies der Orthodoxie des „gesunden Menschenverstands“ um mich herum widerspricht. In der Tat verursachte die zusätzliche Arbeit nicht nur zusätzliche Arbeit, sondern brachte mich in einem kleinen Besprechungsraum zu Tränen. Brooks zitiert zustimmend andere Schriftsteller (S. 276-7), dass die Natur der Arbeit nicht technologisch, sondern soziologisch ist, daher vielleicht der dauerhafte Reiz, für sich selbst zu arbeiten.

Auch sein Standpunkt zu Endbenutzern hat mein Denken beeinflusst. Er sagt, dass es beim Programmieren nicht darum geht, ein Programm zu erstellen, das etwas kann, sondern den Benutzer zufrieden stellt (Spoiler anzeigen)[oder der Käufer, nicht unbedingt dieselbe Person (Spoiler verstecken)] Für mich war dies ein Paradigmenwechsel von der Bereitstellung eines definierbaren technischen Dienstes zur Kundenzufriedenheit, und tatsächlich kann man nuancieren, dass insbesondere wenn Sie an öffentliche Dienste denken, mehrere Parteien unterschiedliche Ergebnisse eines Dienstes erwarten.

Daher kann ich dieses Buch möglicherweise fairerweise nicht allgemein empfehlen. Die Früchte, die ich daraus gepflückt habe, sprechen möglicherweise nicht den Geschmack anderer an. In der Tat finden Sie dort möglicherweise nichts Neues oder Leckeres, insbesondere wenn Sie ein nachdenklicher Anthropologe des Arbeitsplatzes sind.

In der Software mag sein Verfechter des dreimal edlen Mikrofiches für den zeitgenössischen Geschmack zu kurios sein, und im Allgemeinen sind für alle Leser, alle Arbeiter in diesem Buch und alle mutmaßlichen Arbeiter, die auf der ganzen Welt vereint sind, Männer, was für jemanden, der nicht arbeitete Nur in den 50ern, aber in den 70ern und 80ern, scheint mir interessanterweise gedankenlos.

Außer offenem Sexismus * war es ein ziemlich gutes Buch. Es ist eine Reihe von Erfahrungen, die Sie nach und nach sammeln, wenn Sie in der Softwareindustrie arbeiten. Es ist ein wenig veraltet, z. B. haben wir keine gedruckten Handbücher mehr und müssen uns nicht mit den Problemen der ständigen Aktualisierung auseinandersetzen, aber viele Weisheiten aus diesem Buch sind immer noch wertvoll.


* Das gesamte Buch verwendet niemals ein weibliches Pronomen. je. Es klingt wie Ingenieure, Manager, technische Leiter, Kunden sind immer nur Männer. Außerdem gibt es Folgendes:
'Ein Team von zwei, mit einem Führer ist oft die beste Verwendung des Geistes. [Beachten Sie Gottes Plan für die Ehe.] „Mussten Sie Ihre konservativ veralteten patriarchalischen Ansichten wirklich in ein Sachbuch über Informatik aufnehmen?

Ich möchte viele Exemplare dieses Buches drucken.
Ich möchte viele Exemplare drucken und zusammenrollen.
Ich möchte sie zusammenrollen und zu Besprechungen mit meinen Kunden mitnehmen.
Ich möchte sie zu Besprechungen mitnehmen und sie wiederholt über den Kopf schlagen, während ich "mehr ... als ... 30 ... Jahre ... schreie ... und du ... immer noch ... nicht ... verstehst. .. irgendetwas ... hör auf ... mich ... dazu zu bringen ... schlechte ... Software zu schreiben ...! "

Ernsthaft.

Der mythische Mannmonat beginnt stark - mit einer soliden Mischung aus guter Laune, großartigem Geschichtenerzählen und noch besseren Analogien und Metaphern. Am interessantesten ist, dass die Behauptungen, die Frederick Brooks vor mehr als 40 Jahren aufgestellt hat, bis heute zutreffen. Trotzdem ist das Buch nicht gut gealtert.

Die Kapitel 5-8 und 9-15 scheinen völlig veraltet zu sein. Ich gebe unten einige Gründe an, aber das Wesentliche ist, dass die Mitte größtenteils übersprungen werden kann. Schlimmer ist, dass die religiösen Obertöne in diesem Abschnitt etwas außer Kontrolle geraten. Und um noch deutlicher zu machen, wie veraltet es ist, ist der Sexismus weit verbreitet - wo Brooks absichtlich "er" für jedes Pronomen verwendet. Zugegeben, fast alle Programmierer waren zu dieser Zeit Männer, daher ist seine Verwendung nicht irreführend. Aber wenn man es in diesem Zeitalter liest, fühlt es sich so an, als ob das Buch sexistisch sein soll.

Abgesehen von der fragwürdigen Verwendung des Pronomen sind die ersten vier Kapitel, Kapitel 7 und die letzten Kapitel immer noch sehr aufschlussreich. Sie beschreiben hauptsächlich, wie und warum die Softwareentwicklung (auch heute noch) so viel kostet und warum es unwahrscheinlich ist, dass das Hinzufügen von mehr Ingenieuren zu einem Projekt die Produktivität linear beschleunigt.

Das Hauptproblem ist, dass die größten Probleme bei der Softwareentwicklung auf 1) Kommunikation und Organisation und 2) die Verwaltung zusätzlicher Komplexität zurückzuführen sind. In gewisser Weise habe ich das immer gewusst. Aber die Kapitel haben es sehr klar und überzeugend artikuliert.

Ich frage mich, warum technische Interviews so viel für die Problemlösung und kaum für Kommunikations- und Organisationsfähigkeiten oder die Fähigkeit zur Bewältigung der wachsenden Komplexität auswählen.


Ich würde die Kapitel 1-4, 7 und 16+ wärmstens empfehlen. Hier ist eine Zusammenfassung, warum ich den Rest überspringen würde:

Kapitel 5 kann mit Ernest Hemingways berühmtem Zitat zusammengefasst werden: "Der erste Entwurf von allem ist Scheiße." Brooks gibt einige detaillierte Erklärungen darüber, warum der erste Entwurf eines jeden Programms Scheiße ist und wie man sich darauf vorbereitet und darauf umgeht. Kapitel 11 wiederholt dies meistens.

Kapitel 6 beschreibt, wie umständlich das OS / 360-Handbuch wurde. Obwohl aufschlussreich - weil es so lächerlich veraltet ist -, wurden Handbücher größtenteils durch automatisch generierte Websites ersetzt. Aber in den Tagen von OS / 360, als die Ingenieure zum ersten Mal zur Arbeit kamen, wartete ein Stapel Seiten an ihrem Schreibtisch. Diese Seiten stellten die am Vortag am System vorgenommenen Änderungen dar, und der Ingenieur sollte die Seiten im FIVE-FOOT-TALL-Handbuch finden und durch diese neuen Seiten ersetzen. Brooks berichtet über die Probleme bei der Pflege eines solchen Handbuchs und darüber, wie die Umstellung auf ein Mikrofiche-Handbuch in gewisser Weise geholfen, in anderen jedoch behindert hat.

Kapitel 10 behandelt wichtige Dokumente für eine Softwareorganisation. Während diese in einem großen Unternehmen relevant sein könnten, schienen sie in einer Startup-Umgebung ziemlich fehl am Platz zu sein.

In Kapitel 13 werden die Eigenschaften eines guten Testframeworks erläutert, wobei im Wesentlichen die Bedeutung von Komponententests und Integrationstests erläutert wird. Dies ist am modernen Arbeitsplatz eine Selbstverständlichkeit, da zumindest jedes Unternehmen die Bedeutung kennt.

In Kapitel 14 wird ebenfalls die Bedeutung von Meilensteinen oder Hauptzielen mit klar erkennbaren und überprüfbaren Endpunkten erläutert. Auch dies ist am modernen Arbeitsplatz eine Selbstverständlichkeit. Kanban, Agile und jeder andere Software Development Life Cycle dreht sich hauptsächlich darum.

In Kapitel 15 wird die Bedeutung der Dokumentation erläutert. Brooks blickt jedoch in die Zukunft und sieht, dass dies überholt ist. Er gibt zu, dass neuere Sprachen der damaligen Zeit wie Ada es ermöglichten, dass Code fast von Menschen gelesen werden kann. Heutzutage ist Code so lesbar, dass die meisten Programmierer es vorziehen, dass Code "selbstdokumentierend" ist. Es steht immer zur Debatte, ob der geschriebene Code tatsächlich selbstdokumentierend ist. Die Bedeutung der Dokumentation nimmt jedoch ständig ab, da die Sprachen immer aussagekräftiger werden und die Systeme immer besser gestaltet werden.

Ich habe dieses Buch ursprünglich im College gelesen und es dann nach ein paar Jahren professioneller Codierung erneut gelesen. Während es sicherlich einige datierte Abschnitte gibt, wie zum Beispiel die Idee, das Analogon eines Operationsteams zum Codieren zu haben, haben sich viele der Vorschläge gegen den Test der Zeit ausgesprochen.

Die beiden beliebtesten sind "keine Silberkugeln" und "das Hinzufügen von Entwicklern zu einem späten Projekt macht es später". Ersteres ist, dass keine neue Technologie / Technik vor über 10 Jahren einen Produktivitätsunterschied um eine Größenordnung bewirken wird. Dies ist besonders wichtig, wenn Sie sich mit Anbietern oder dem neuesten Proselytizer einer Sprache oder Prozessideologie befassen. Ich finde, dies ist eine schöne Ergänzung zu Robert Glass 'Meinung, dass der größte Unterschied in produktiven Teams die Qualität der Entwickler ist. Der zweite ist selbsterklärender. Die Anlaufkosten für das Hinzufügen neuer Entwickler übersteigen den Wert, den sie innerhalb eines angemessenen Zeitraums liefern werden.

Es gibt auch weniger referenzierte Lektionen, die aus dem Buch entnommen werden können. Zum Beispiel hat dieses Buch lange vor Agile die Entwicklung von Wasserfällen zugunsten eines iterativen Ansatzes vermieden. Meine Lieblingsstunde in diesem Buch ist die konzeptionelle Integrität. Im Wesentlichen bezieht sich Brooks auf die Idee, dass eine Software eines gut machen sollte, und wenn sie versucht, viele Rollen zu übernehmen, passt sie nicht für alle, sondern gut für eine. Als Beispiel nennt er mehrere Kathedralen, deren Fertigstellung Jahrhunderte dauerte. Die Kathedralen, die in der mittleren oder späteren Bauphase egoistischen Architekten zum Opfer fielen, sind weniger ästhetisch konsistent und daher ansprechend als diejenigen, bei denen der ursprüngliche Stil respektiert wurde.

Brooks empfiehlt außerdem, zwei unabhängige Karrierestrecken für Entwickler beizubehalten. In vielen Organisationen werden Entwickler nach einer bestimmten Stufe zum Management gezwungen. Brooks argumentiert, dass dies ein Fehler ist und dass es in vielen Fällen besser ist, einige Entwickler Entwickler bleiben zu lassen. Dies erfordert eine Titel- und Vergütungsparität mit dem Management-Track.

Während viele der technologie-spezifischen Beispiele datiert sind, wird Mythical Man Month für jeden Entwickler empfohlen.

Ich war überwältigt davon, wie stark dieser Text gealtert ist. Die Referenzen, die vor 15 Jahren Sinn machten, enthalten kein Wasser mehr, und das Projekt mit den meisten Referenzen ist heutzutage sicherlich nicht mehr die Art und Weise, wie wir Software schreiben. Während die Idee gültig bleibt, denke ich, dass Leute, die über diesen Text schreiben, relevanter sind als der Text selbst und höchstens historischen Wert haben.

Ich bin wirklich überrascht, dass die Leute dieses Buch immer noch empfehlen. Es handelt sich hauptsächlich um sehr große Softwareprojekte (dh ein Betriebssystem), ein Großteil der "Daten" ist anekdotisch und viele der Annahmen sind einfach veraltet. Zum Beispiel schreibt Brooks über (1) das Erstellen von Papierhandbüchern mit Dokumentation über das System, die täglich für die Ingenieure aktualisiert werden, (2) Strategien für die Zeitzuweisung auf zentralisierten Computern und (3) über die Optimierung der kompilierten Codegröße. Außerhalb von Nischenanwendungen sind das einfach keine Probleme mehr.

Darüber hinaus wird Brooks 'Hauptthese über Mannmonate am häufigsten falsch zitiert und missverstanden. Er schreibt, dass Menschen und Monate nicht austauschbar sind und dass Menschen hinzugefügt werden spät Projekte werden sie erst später machen - weil die Leute zunächst einen negativen Beitrag leisten. Die Details dieses Aphorismus sind unglaublich wichtig, aber immer vergessen.

Es wäre schön, ein neues, aktualisiertes Buch zu diesem Thema zu sehen, das aktuelle Daten und Messkonzepte aus diesem Jahrhundert enthält. Aber ich fand Brooks 'Artikulation einiger anderer Konzepte hilfreich. Unter ihnen:

Simplicity and straightforwardness proceed from conceptual integrity.

By documenting a design, the designer exposes himself to the criticisms of everyone, and he must be able to defend everything he writes. If the organizational structure is threatening in any way, nothing is going to be documented until it is completely defensible.

All repairs tend to destroy the structure, to increase the entropy and disorder of the system. Less and less effort is spent on fixing original design flaws; more and more is spent on fixing flaws introduced by earlier fixes. As time passes, the system becomes less and less well-ordered. Sooner or later the fixing ceases to gain any ground. Each forward step is matched by a backward one. Although in principle usable forever, the system has worn out as a base for progress.

en bilinen kısmı unutmuşum :) „Die Geburt eines Kindes dauert neun Monate, unabhängig davon, wie viele Frauen zugewiesen sind. Viele Softwareaufgaben haben diese Eigenschaft aufgrund der sequentiellen Natur des Debuggens. “

Ich habe dies kürzlich erneut gelesen, nachdem ich es einem Kollegen empfohlen hatte, hauptsächlich wegen Nostalgie und weil ich vorhatte, einige der populäreren Essays wie "The Tar Pit" zu lesen. Stattdessen las ich das gesamte Buch noch einmal und fand es immer noch frisch und aufschlussreich, über 40 Jahre seit Veröffentlichung. Die Prosa ist voller Ideen, aber brillant klar und oft witzig. Jetzt, wo ich zeitgenössisches Schreiben lese (Blogs, aber auch Bücher), beklage ich diese verlorene Kunst zutiefst.

Abgesehen von seinen kühnen Aussagen, vor allem dem Brooks'schen Gesetz, die bis zum Klischee zitiert wurden, fiel mir diesmal am meisten auf, wie sehr seine Begeisterung für den Aufbau von Systemen und die Führung von Teams zum Ausdruck kommt. Man würde erwarten, dass ein Veteran von massiven IBM-Projekten etwas erschöpft ist, aber ich persönlich fand seine Beschreibungen dessen, was Bauherren am Bauen lieben, ziemlich schön. Wenn ich in seinem Alter halb so verliebt in mein Handwerk bin, fühle ich mich glücklich.

IMHO steht dies ganz vorne Peopleware und Psychologie der Computerprogrammierung as Unentbehrliche Lektüre für technische Führungskräfte. Die spezifischen Referenzen, selbst aus dem Abschnitt zum 2-jährigen Jubiläum, sind datiert (MS Works-Fans da draußen?), Aber 80% der gemachten Punkte sind keinen Tag gealtert. Wenn überhaupt, werden die veralteten Abschnitte eine ernüchternde Erinnerung daran sein, dass Ihr Macbook im Grunde ein Supercomputer ist, den Sie für Ihren eigenen exklusiven Gebrauch in den Zug bringen können. Ich bin so dankbar, dass ich mich nicht mehr um die Größe meiner Funktionen im Speicher kümmern muss und schöne, interpretierte Sprachen wie Ruby im Web-Maßstab verwenden kann, um beispielsweise diese Website zu betreiben ;-)

Einige Rezensenten haben festgestellt, dass nur männliche Pronomen ausgeschlossen sind. 1975 (vor der PC-Ära) gab es tatsächlich weit mehr weibliche Programmierer, daher muss ich davon ausgehen, dass dies eine rein schwerfällige Konvention ist (und in den Add-On-Kapiteln von 1995 nicht verwendet wurde). Und ja, es gibt einige religiöse Untertöne, die überall verstreut sind, aber sie haben die Ideen für mich nicht behindert.

Sehr, sehr zu empfehlen. Ein großartiges Buch, das Sie mit Ihrem Team lesen können, um Kriegsgeschichten auszutauschen.

Dies ist heutzutage mehr von historischer Bedeutung als ein Buch zum Mitnehmen. Trotzdem bin ich froh, es gelesen zu haben.

Ich stimme den darin enthaltenen Punkten zu zwei Bewertungen, insbesondere die über den männlichen Standardprogrammierer und den überdehnten christlichen Standpunkt, was Brooks tatsächlich zu einem seiner Beispiele macht.

Trotzdem liebte ich die positive und realistische Botschaft: "Es gibt keine königliche Straße, aber eine Straße." Ich kann hinter beiden Teilen dieses einen stehen.

Interessantes Buch mit einem ziemlich engen Fokus, eine Sammlung von Aufsätzen über das Management und die Planung guter Softwareentwicklung. Der Autor hat die Fehler und Erfolge seiner Arbeit am IBM 360-Betriebssystem in den 70er Jahren eingeflößt, und das meiste, was er gefunden hat, gilt noch heute. Zum Beispiel Weisheit wie: Mehr Programmierer machen ein Projekt nur spät, und wenn Sie einem bereits verspäteten Projekt Programmierer hinzufügen, werden die Ergebnisse noch später eintreffen. Haben Sie einen Architekten und einen Manager, hoffentlich in zwei verschiedenen Personen. Versionskontrolle haben (da das Buch alt ist, ist es eher ein zentrales Repository für gedruckte (!!) Bücher, in denen alle Änderungen, die Gliederung, das Design usw. detailliert aufgeführt sind). Es gibt keine Silberkugel - Software ist von Natur aus komplex und es wird nie eine einzige Technologie geben, die sie schnell / einfach / billig / fehlerfrei macht.

Ein großer Teil des enthaltenen Wissens sind nützlichere große Unternehmen oder große Projekte, in denen 100 bis 1000 Programmierer gleichzeitig arbeiten. Für mich als einsamen Bioinformatiker, der sich mit meinem eigenen Code beschäftigt, ist also nicht alles anwendbar. Aber wenn ich mir beispielsweise fehlgeschlagene Projekte bei Kickstarter ansehe, stelle ich fest, dass sie oft nur Fehler wiederholen, die Menschen bereits in den 70er Jahren gelöst haben.

Diese Bewertung enthält eine gute Zusammenfassung der wichtigsten Punkte.

Ich gebe ihm 4 Sterne, da einige der Beispiele, Diskussionen und Probleme inzwischen eindeutig veraltet sind.

Viele Male, wenn ich ein datiertes Buch lese, sind seine Perlen der Weisheit immer noch da, um geerntet und genutzt zu werden. Ich kann nicht dasselbe über den Mythical Man Month sagen. Ich werde zugeben, dass Brooks Gesetz immer noch gilt, und Manager stolpern noch heute über dieses. Ein Großteil seiner Ratschläge fiel jedoch angesichts der jüngeren agilen Entwicklungsbewegung und der noch neueren Devops-Bewegung flach. Am Ende predigte er immer noch eine Art wasserfallartigen Entwicklungsansatz, der sich immer wieder als mangelhaft herausstellte. Außerdem klatschte seine Prosa nach jemandem, der sich nur in seine eigenen Gedanken verliebte. Der Monat des mythischen Mannes fiel meiner Einschätzung nach letztendlich flach, obwohl ich verstehen kann, warum es zu einem bestimmten Zeitpunkt ein hochgelobtes Buch war. Ich denke, es wäre besser, wenn jemand die wahren Weisheiten aus dem Mythical Man Month herausholen und ein neues Buch schreiben würde, das den Stand der Technik berücksichtigt und einen Ton hat, der weniger selbstlobend ist.

04

Dr. Brooks ist der Gründer unserer Abteilung, mehr als genug Grund, sein Buch zu lesen.

Die kürzliche Erweiterung unseres Abteilungsgebäudes war benannt nach Dr. Brooks. Anscheinend kam das Geld für das Gebäude als anonyme Spende eines Alumnus, unter der Bedingung, dass es nach Dr. Brooks benannt wurde. Das ist die Art von Respekt, die er von mehreren Menschen gewonnen hat.

Dieses Buch hatte einige aufschlussreiche Ideen zu Software-Engineering-Praktiken, aber ein großer Teil des Buches ist nicht mehr relevant.

Der Autor ging auf einige spezifische Details zu Situationen ein, auf die er gestoßen war, z. B. Praktiken, bei denen Entwickler planten, wie sie die Debugging-Computer unter sich aufteilen würden.

Moderne Maschinen können viel mehr als Computer in den 70er Jahren, und dieses Buch muss aktualisiert werden, um dies widerzuspiegeln.

Die wichtigsten Erkenntnisse aus diesem Buch sind, dass die Softwareentwicklungspraktiken flexibel sein müssen, um den sich verändernden / unbekannten Anforderungen der Software gerecht zu werden. Es ist eine schlechte Idee, einem späten Projekt mehr Ingenieure hinzuzufügen, und die Dokumentation ist möglicherweise schwer zu warten Es ist eine gute Idee, nur Absätze der Dokumentation in den Code selbst einzufügen (um zu verhindern, dass der Code nicht mehr mit der Dokumentation synchronisiert wird).

* Die Schätzung der Fertigstellungszeit von Softwareprojekten ist sehr schwierig. (Anforderungen ändern sich, Software ist nicht greifbar und muss mit den Besonderheiten menschlicher Systeme übereinstimmen.)

* Aristokratie bei der Verwaltung von Projekten ist besser. Es sollte einen endgültigen Entscheidungsträger geben. Metapher ist ein chirurgisches Team.

* Die Kosten für Koordination und Kommunikation in großen Teams werden häufig ignoriert. Dies führt zu einer schlechten Schätzung.

* Wenn sich ein Projekt verzögert, wird eine Neuplanung oder Reduzierung des Umfangs empfohlen. Das Hinzufügen von Arbeitskräften führt zu weiteren Verzögerungen.

* Vermeiden Sie das Überfüllen von Funktionen im zweiten System (erinnerte mich an Vista)

* Die schriftliche Spezifikation ist sehr wichtig. Es sollte alles beschreiben, was der Benutzer über das Produkt sehen kann.

* Der Algorithmus kann aus den Datentabellen vorhergesagt werden.

* Eine kleine Anzahl von Dokumenten wird zum Dreh- und Angelpunkt des Produktmanagements (Ziele, Spezifikationen, Zeitplan, Budget).

* Quantifizierung der Änderung anhand von Versionsnummern

* Mit zunehmender Anzahl der Benutzer werden mehr Fehler gefunden

* Am Anfang sind die Dinge immer am besten

* Reparaturen (Software) erhöhen die Entropie

* "Anhaltende Konzentration verkürzt die Denkzeit"

* Meilenstein sollten konkrete, spezifisch messbare Ereignisse sein. Achten Sie genau auf die geringsten Verzögerungen. Projekte werden jeweils um einen Tag verzögert.

* Der schwierige Teil beim Erstellen von Software ist: Spezifikation, Design und Testen

* Kreative Aktivität besteht aus drei Schritten:
1. Formulierung des konzeptuellen Konstrukts
2. Implementierung in realen Medien
3. Interativität mit Benutzern in realen Anwendungen

* "Die konzeptionelle Integrität des Produkts, wie sie vom Benutzer wahrgenommen wird, ist der wichtigste Faktor für die Benutzerfreundlichkeit."

* Verwenden Sie Tastaturkürzel, um für Power-User und Anfänger zu entwerfen

* "Menschen mit mehr Zeit brauchen mehr Zeit"

* Empfohlene Bücher: Peoplware: Productie Project-Teams und Small is Beautiful

Faszinierende Reihe von Aufsätzen über das Erstellen von Software und das Verwalten von Teams. Einige Teile fanden großen Anklang, insbesondere in Bezug auf das Handwerk der Softwareentwicklung. Brooks sagte, dass der schwierigste Teil beim Erlernen des Programmierens darin besteht, sich auf die Notwendigkeit der Perfektion einzustellen, was meiner Meinung nach bis heute zutrifft. Er hatte auch die zutreffendste Beschreibung, wie es sich anfühlt, tatsächlich Code zu schreiben, und die Unterschiede zwischen der wesentlichen Arbeit beim Erstellen von Software und der "zufälligen" Arbeit, die durch schlechte Werkzeuge, Prozesse und die Macken von Computern verursacht wird.

Leider hat Mythical Man-Month ein Geschlechterproblem. Jedes Pronomen war "er", mit Ausnahme der gelegentlichen Verweise auf Sekretärinnen und Krankenschwestern, die natürlich Frauen sind. Darüber hinaus enthält das Buch (einige) schräge Hinweise auf den Platz von Frauen in der Wohnung. Es ist grob, unnötig und unglaublich frustrierend. Zeit für eine Ausgabe 2016.

Dies ist ein Meisterwerk der Softwareentwicklung. Viele Leute haben diesen gelesen, weil dieser ein äußerst zugänglicher Bericht ist. Als ich dieses Buch 2007 las, spürte ich, wie viel Wert dieses eine Buch brachte, das vor mehr als 20 Jahren geschrieben wurde, selbst dann. Seitdem habe ich viele Menschen über dieses Buch sprechen und schwören hören. Ich habe einen Kritikpunkt gegen die Leser und Leute, die darüber sprechen. Sie benutzen dieses Buch, um ihre Haltung zu unterstützen, und meistens besitzen diese Leute nicht die Art von Fachwissen und Erfahrung, die Fred Brooks besaß. Ich hoffe, wir alle lesen dies als unterhaltsamen Bericht und versuchen, einige Einblicke in den Prozess der Softwareentwicklung zu bekommen.

Ich habe es im Rahmen meiner Promotion gelesen, da es Teil der klassischen Bücher der Softwareentwicklung ist. Das Buch befasst sich jedoch nicht nur mit sehr wichtigen Fragen des Managements, sondern auch mit der Interaktion der Menschen während der Softwareentwicklung. Ich habe mich in vielen vom Autor beschriebenen Situationen wiedererkannt (auch wenn ich nicht Teil eines Softwareentwicklungsteams bin).
Man mag sich wie ich fragen, wie viele der vom Autor erläuterten Konzepte auf die aktuelle Technologie des 21. Jahrhunderts zutreffen, aber der Autor geht das in den letzten Kapiteln an. Es gilt jedoch fast alles, da der Schwerpunkt des Buches auf den allgemeinen Lektionen liegt, die niemals veraltet sind.

Jeder sollte dieses Buch lesen, nicht nur Programmierer oder Projektmanager. Es ist einfach und macht Spaß. Es gibt 9 Kapitel, von denen Sie jedoch nur 3 lesen müssen. Sie werden wissen, welche. Wenn er anfängt, Gleichungen zu schleudern, überspringen Sie diese Teile. Er verwendet Kochmetaphern, während die meisten Softwarebücher Gebäudekonstruktionsmetaphern verwenden. Die für diese Zeit typische unbewusste geschlechtsspezifische Tendenz ist fast lustig. Er sagt immer wieder, wie viele "Männer" es braucht, um ein Projekt zu machen.

Ich bin häufig überrascht, wie viele Softwareprofis dieses Buch noch nie gelesen haben, noch nie von Brooks Gesetz oder dem zweiten Systemsyndrom gehört haben (und darunter leiden).

Selbst für einen unerfahrenen Studenten wie mich machte dieses Buch einen bleibenden Eindruck und ließ mich über die verschiedenen menschlichen Dynamiken nachdenken, die mit Software-Engineering verbunden sind. Auf jeden Fall ein Muss.

Warnung: Es wird manchmal etwas trocken und die meisten Beispiele sind sehr veraltet, aber die erklärten Prinzipien sind zeitlos.

Brooks Buch wurde 1975 vor der PC-Explosion Mitte der 1980er Jahre geschrieben und ist bis heute relevant. Dieselben "Faustregeln" für das Systemmanagement und potenzielle Fallstricke bestehen immer noch in weitgehend derselben Form. Viele seiner größeren Lektionen gehen über die reine Softwareentwicklung hinaus und gelten für das gesamte Programmmanagement. Ein Muss für jeden, der komplexe Systeme entwickelt.

Veraltet, unnahbar und in gewisser Weise frauenfeindlich (systemisch, aber ungewollt, da bin ich mir sicher). Ich verstehe wirklich, warum dies immer noch das beliebteste Programmierbuch Nr. 2 bei Safari Books Online ist (direkt nach Clean Code).

Wahrscheinlich macht mehr als die Hälfte der Lektionen und Vorschläge in der modernen Welt der Hochsprachen, der agilen Softwareentwicklung und der kontinuierlichen Entwicklung / Veröffentlichung keinen Sinn.

Andere Lektionen sind immer noch weit verbreitet ... so weit verbreitet, dass sie bereits nahezu universelles Wissen sind. Dinge wie selbstdokumentierender Code sind ideal, wenn Sie in letzter Minute Personal hinzufügen, sparen Sie nicht, eine genau definierte Spezifikation reduziert Fehler usw.

Ich werde wiederholen, was einige andere gesagt haben, dass ich das letzte Viertel des Buches (Kapitel 1+) als das wertvollste empfunden habe und es hier immer noch einen gewissen Wert gibt. Ich habe immer daran gedacht, ein Computerprogramm zu erstellen, nicht zum Beispiel eines. Oder diese einzelne Zeile über Kommentare, die angeben müssen, * warum * Sie etwas getan haben, nicht wie Sie es getan haben.

Es gibt auch wirklich seltsame und geradezu erschütternde Momente. Die Systementwicklung ist anscheinend genau wie die Heilige Dreifaltigkeit. "Ja wirklich?" Ja wirklich?? Inwiefern ist die Systementwicklung wie der Vater, der Sohn und der Heilige Geist?

Das Lesen dieses Buches war für mich eine Zeitreise. Aus heutiger Sicht ist es ein ziemlich veraltetes Buch. Es war erstaunlich, über völlig andere alltägliche Probleme wie Techniken und Strategien zur Aktualisierung der papierbasierten Dokumentation zu lesen.

Trotz der heutigen agilen Techniken und Erfahrungen früherer Generationen haben Softwareentwickler, Architekten und IT-Projektmanager immer noch Probleme mit einigen Problemen wie der korrekten Projektschätzung von Zeit und Kosten. Viele Regeln sind immer noch gültig, wie das Brook'sche Gesetz besagt, dass das Hinzufügen von Personen zu späten Projekten erst später erfolgt.

Dieses Buch zeigt, dass jede Generation von IT-Fachleuten ihre eigenen Herausforderungen hat, um mit Heraklit umzugehen und ihn zu paraphrasieren. Veränderungen sind die einzige Konstante in der Softwareentwicklung.

Im Zusammenhang mit dieser Geschichte der Best Practices für Softwareentwicklung und -verwaltung zum effektiven Erstellen von Softwaresystemen und zum Verwalten von Projekten und Teams aller Größenordnungen ist dieses Buch von unschätzbarem Wert. Ich empfehle jedem Softwareentwickler, der daran interessiert ist, Softwaresysteme auf Metaebene zu erstellen (technische / soziale Systeme, die Ihnen beim Erstellen von Softwaresystemen helfen) oder einen Einblick in diese Prozesse erhalten möchte. Bemerkenswerterweise haben sich seit dem Schreiben dieses Buches nur die genannten spezifischen Methoden und Werkzeuge geändert. Der Großteil der übergeordneten Diskussionen über die Softwarearchitektur und die Verwaltungsprozesse scheint zeitlos zu sein!

So viel von diesem Buch ist urig. Die Beschreibungen der Dokumentation, die ausgedruckt werden muss, um gemeinsam genutzt zu werden, Computersysteme, auf denen die zu erstellenden Programme kaum ausgeführt werden können ... mit all den technischen Fortschritten würden Sie denken, wir wären weiter in unserem Verständnis von wie man dieses Zeug baut. Im Gegenteil, die Teams unterliegen immer noch denselben Problemen, die beschrieben wurden, und die gegebenen Ratschläge gelten ebenso.

Der erste Teil des Buches ist das Original aus dem Jahr 1975. Die meisten der vom Autor aufgeführten allgemeinen Ideen sind interessant, aber er konzentriert sich auf sehr große Teams (Entwicklung von Betriebssystemen, Compilern usw.), die mit mittlerweile sehr veralteten Technologien arbeiten und ganz andere Probleme lösen Probleme. Zum Glück war es ziemlich kurz. 2/5.

Der zweite Teil des Buches ist eine Zusammenfassung des Originalbuchs und Überlegungen des Autors nach 20 Jahren. Dies war viel einfacher zu lesen, da die Gedanken von 1995 besser zu verstehen sind. Nachdem Brooks 20 Jahre lang Feedback erhalten hatte, änderte er auch einige seiner Meinungen zu Themen, die im Originalbuch beschrieben wurden, was aus historischer Sicht gut zu lesen war. 4/5.