Buchbesprechung: The Mythical Man-Month: Essays on Software Engineering, Jubiläumsausgabe

Der Mythical Man-Month (MM-M) von Frederick P. Brooks Jr. ist eines der bekanntesten Bücher in der gesamten Softwareentwicklungsliteratur und wohl DAS bekannteste Buch über Softwareentwicklungsmanagement. Es gibt bereits unzählige Rezensionen zu dieser Klasse, aber ich überprüfe sie in diesem Beitrag noch einmal für diejenigen Softwareentwickler, die sie nicht gelesen haben und einen kleinen Überblick darüber wünschen, was sie daran mögen. Immerhin ist es der Titel Nr. 1 von PC World in der Liste der zehn besten IT-Bücher, die Sie niemals nicht gelesen haben. Der vollständige Titel der Ausgabe, die ich in diesem Beitrag überprüfe, lautet The Mythical Man-Month: Essays on Software Engineering, Jubiläumsausgabe.

Die "Anniversary Edition" des Mythical Man-Month (veröffentlicht 1995) fügt bedeutende Inhalte hinzu, die über das hinausgehen, was 1975 in der Originalausgabe veröffentlicht wurde. Die "Anniversary Edition" enthält das Originalbuch in seiner ursprünglichen Form (allerdings mit der Aufnahme) der im Nachdruck von 1982 hinzugefügten Korrekturen) und fügt vier neue Kapitel hinzu. Die ersten fünfzehn Kapitel der Jubiläumsausgabe sind die Kapitel aus dem Originalbuch. Zu den hinzugefügten Kapiteln gehören Brooks 'separates, aber ebenso berühmtes IFIPS (1986) / IEEE Computer Magazine (1987) -Papier No Silver Bullet: Essenz und Unfälle der Softwareentwicklung sowie ein Follow-up namens No Silver Bullet ReFired. Die Kapitel 18 und 19 der Jubiläumsausgabe konzentrieren sich auf Brooks 'Selbstperspektive von 1995 auf das, was er 1975 schrieb.Brooks weist darauf hin, was er falsch und was richtig gemacht hat (es gibt weit mehr Fälle von letzterem als von ersteren).

Es gibt zahlreiche Rezensionen zu The Mythical Man-Month , die eine umfassende Berichterstattung über die Themen und Zitate aus diesem Buch enthalten (Wikipedia-Artikel, Bernard I. Ngs Zusammenfassung The Mythical Man-Month, Einige Einblicke aus The Mythical Man Month ab Kapitel 11, The Mythical Man-Month - Auszüge I, The Mythical Man-Month - Auszüge II, The Mythical Man-Month Lecture und Review / Zusammenfassung des Mythical Man-Month zum Beispiel). Anstatt einen Überblick über den gesamten Inhalt des Buches zu wiederholen, konzentriere ich mich in diesem Beitrag auf einige wichtige Punkte und im Lichte einiger Best Practices und Ideologien moderner Software.

Kapitel 19 ("Sätze des mythischen Menschenmonats": Richtig oder falsch? ") Der" Anniversary Edition "wird besonders den Leser ansprechen, der ungeduldig ist oder nicht die Zeit hat, das gesamte Buch zu lesen, aber einen Überblick über Brooks 'Behauptungen erhalten möchte. Weil Brooks dieses Kapitel zur Präsentation verwendet "Die Essenz des Buches von 1975" in "Umrissform", Brooks 'Behauptungen ("Fakten und Verallgemeinerungen vom Typ Faustregel aus Erfahrung") aus seinem ursprünglichen Buch werden in "starker Form" (ungefähr 20 Seiten) präsentiert Das Vorhandensein dieses Kapitels in der "Anniversary Edition" ist ein weiterer Grund, warum ich das Buch hier nicht Kapitel für Kapitel aufschlüssele. Dieses Kapitel fasst mehr als nur die Behauptungen aus dem Originalbuch zusammen, es enthält auch einige von Brooks 's Kommentare von 1995 basieren auf weiteren 20 Jahren Beobachtung und dem Nutzen der Rückschau.

In seinem Beitrag The Mythical Man Month: Buchbesprechung schließt Mark Needham seine Rezension dieses Buches mit der Aussage ab: "Ich habe es wirklich genossen, dieses Buch zu lesen und zu sehen, wie viele Ideen in moderneren Methoden bereits in den 1980er und 1980er Jahren bekannt waren sind im Wesentlichen keine neuen Ideen. " Ich stimme dieser Aussage voll und ganz zu, obwohl die Wahrheit möglicherweise noch erstaunlicher ist: Dies waren Beobachtungen in einem 1975 veröffentlichten Buch, das auf Brooks 'Erfahrungen mit der Entwicklung von OS / 360 Mitte der 1960er Jahre und auf anschließenden Gesprächen in beruhte das Ende 1960s. Mit anderen Worten, einige der Dinge, die wir heute für "neu" oder "trendy" halten, gibt es schon seit 45 Jahren oder länger! Als Randnotiz erinnert mich dies an eine Präsentation von Alan M. Davis vor der Denver Java Users Group ("Was ist neu an neuen Methoden der Softwareentwicklung?") Ende 2006, in der er demonstrierte, wie viele der "neuen" Methoden und Die Taktik von heute hat in den vergangenen Jahren sehr ähnliche Vorgänger und wie wir über Jahrzehnte zwischen ihnen zu wechseln scheinen.

Die folgenden Punkte von Brooks sind besonders interessant, wenn man den Gedanken im Hinterkopf behält, dass dieses Buch 1975 aufgrund von Erfahrungen Mitte bis Ende der 1960er Jahre veröffentlicht wurde (diese Zitate stammen jedoch aus der Zusammenfassung von Kapitel 19) basieren auf dem Text der Ausgabe von 1975):

  • "Sehr gute professionelle Programmierer sind zehnmal so produktiv wie arme ..." [Handwerkskunst]
  • "Ein kleines scharfes Team ist am besten - so wenig Verstand wie möglich." [Agil]
  • "Die Behebung eines Fehlers hat eine erhebliche Wahrscheinlichkeit (20 bis 50 Prozent), einen weiteren Fehler einzuführen. Nach jeder Behebung muss die gesamte Reihe von Testfällen ausgeführt werden, die zuvor gegen ein System ausgeführt wurden, um sicherzustellen, dass es nicht auf dunkle Weise beschädigt wurde." [Regressionstests]
  • "Es lohnt sich, viele Debugging-Gerüste und Testcodes zu erstellen, vielleicht sogar 50 Prozent so viel wie das zu debuggende Produkt." [Unit Testing]
  • "Um die Dokumentation aufrechtzuerhalten, ist es entscheidend, dass sie in das Quellprogramm aufgenommen wird und nicht als separates Dokument aufbewahrt wird. Selbst die Syntax auf hoher Ebene vermittelt überhaupt keinen Zweck." [TROCKENES Prinzip]

Es gibt viele weitere Beobachtungen in The Mythical Man-Month, die zeigen, dass Brooks und andere Entwickler dieser Zeit viele der gleichen Grundlagen der Softwareentwicklung verstanden haben, die wir heute verstehen (und manchmal wieder "entdecken"). Viele davon sind bekannter und werden in anderen Rezensionen erwähnt. Daher liste ich sie hier nicht auf, mit Ausnahme dieser Zitate, die man unbedingt auflisten muss:

  • "Aus Mangel an Kalenderzeit sind mehr Softwareprojekte schief gelaufen als aus allen anderen Gründen zusammen."
  • Brookes Gesetz: "Das Hinzufügen von Arbeitskräften zu einem späten Softwareprojekt macht es später."
  • "Daher ist der Mannmonat als Einheit zur Messung der Größe eines Arbeitsplatzes ein gefährlicher und trügerischer Mythos."

Einer der Abschnitte, die ich besonders aktuell fand (insbesondere für ein Buch von 1975 im Jahr 2011), war Brooks 'Berichterstattung darüber, wie ein Softwarearchitekt die Implementierung beeinflussen kann. Dies kann besonders empfindlich sein, wenn die Vision des Architekten vom Entwickler nicht in der vom Architekten gewünschten Weise umgesetzt wird. Brooks Tipps scheinen sehr praktisch zu sein. Er erklärt, dass der Architekt sich damit abfinden muss, dass die Person, die den Code implementiert, "kreative Verantwortung" für diese Implementierung hat. Er rät ferner, dass der Architekt immer eine Idee haben sollte, einen seiner Entwürfe umzusetzen, aber gleichzeitig bereit sein muss, einen ebenso guten alternativen Ansatz zu akzeptieren, der von der Person vorgeschlagen wird, die den Kodex implementiert. Brooks empfiehlt dem Architekten ferner, alle Vorschläge zur Implementierung zu machen. "Seien Sie ruhig und privat "bereit", auf Kredit zu verzichten, und hören Sie sich die "Vorschläge des Implementierers für Architekturverbesserungen" an. Dies scheint mir ein guter Rat zu sein, der auf meinen Erfahrungen auf beiden Seiten dieser Beziehung basiert.

In dem Artikel von 2005, der häufig zitiert wird und selten folgt, stellt Brooks fest:

In dem Buch geht es wirklich mehr um Management als um Technologie. Die Technologie hat sich immens geändert, sodass einige der alten Kapitel nicht mehr synchron sind. Andererseits haben sich die Leute nicht viel verändert. Deshalb sind Homer und Shakespeare und die Bibel immer noch relevant, weil sie sich alle mit der menschlichen Natur befassen. Ich denke, das ist ein Teil der Erklärung für dieses Buch: Die Probleme beim Verwalten von Personen in Teams haben sich nicht geändert, obwohl das Medium, in dem Personen entwerfen, und die Tools, die sie verwenden, vorhanden sind. Einige Leute haben das Buch die "Bibel der Softwareentwicklung" genannt. Ich würde dem in einer Hinsicht zustimmen: Das heißt, jeder zitiert es, einige Leute lesen es und einige Leute gehen daran vorbei.

Die in diesem Zitat enthaltenen Konzepte sind möglicherweise das Wichtigste, was in einem Rückblick auf The Mythical Man-Month zu vermitteln ist. Der Reiz des Buches liegt in der Berichterstattung über und dem Fokus auf das Management von Menschen. Das ist über die Jahrzehnte zeitlos und unverändert geblieben. Die Technologien haben sich definitiv erheblich verändert und das könnte das größte Negative an diesem Buch sein. Brooks Beispiele, die 1975 auf bestimmten Produkten, Werkzeugen und Sprachen basierten, waren damals sicherlich anschaulicher als heute für den typischen Leser. Zum Beispiel nennt sein Buch von 1975 PL / I "den einzigen vernünftigen Kandidaten für die heutige Systemprogrammierung". Manchmal kann ein Teil des Lesens etwas schwieriger sein, da es an direkter Erfahrung mit den Produkten mangelt, die Brooks erwähnt. In den meisten Fällen ist dies jedoch am Ende kein großes Hindernis, da das menschliche Element im Mittelpunkt des Buches steht und dies bis heute größtenteils unverändert bleibt. In Kapitel 19 der JubiläumsausgabeBrooks reflektiert die anhaltende Popularität seines Buches und erklärt: "In dem Maße, wieBeim MM-M geht es um Menschen und Teams, die Veralterung sollte langsam sein. "

Der Mythical Man-Month handelt wirklich von sehr großen Projekten zur Entwicklung von Unternehmenssoftware. Dies ist wichtig, wenn Sie Dinge lesen, die für jemanden, der an einem kleinen Projekt arbeitet, offensichtlich erscheinen. Der letzte Teil des obigen Zitats ist berühmt: "Einige Leute haben das Buch die 'Bibel der Softwareentwicklung' genannt. Ich würde dem in einer Hinsicht zustimmen: Das heißt, jeder zitiert es, einige Leute lesen es und einige Leute gehen daran vorbei. " Brooks Buch ist mit biblischen Referenzen gefüllt und er ist offensichtlich mit der Heiligen Bibel vertraut. Leider ist Brooks Zitat "Jeder zitiert es, einige Leute lesen es und einige Leute gehen daran vorbei" heute nur allzu wahr. Wir werden es weiter lesen, aber es wäre schön, mehr zu tun, um Dinge in großen Softwareentwicklungsprojekten zu ändern.

Einige Leute fühlen, dass der mythische Mann-Monatist defätistisch und sogar deprimierend. Ich habe nicht das gleiche Gefühl, wenn ich es lese. Ich denke eher, dass es uns daran erinnert, dass bestimmte Verhaltensweisen schädlich und dysfunktional sind. Es erinnert uns auch daran, dass wir nicht auf das "nächste große Ding" warten sollten, sondern stattdessen unser Handwerk weiter verbessern sollten, so gut wir können. Viele praktische Tipps und Vorschläge werden bereitgestellt. Brooks liebt es offensichtlich, im Bereich der Softwareentwicklung tätig zu sein, und dies wird in seinem Buch immer wieder gezeigt. Brooks schließt den "Epilog: Fünfzig Jahre des Wunders, der Aufregung und der Freude" des Buches ab und spricht darüber, wie er früher "alle Zeitschriften und Konferenzberichte lesen" konnte, aber schließlich bestimmte Interessen einzeln aufgeben musste Wissen explodierte. Er kommt zu dem Schluss: "Zu viele Interessen, zu viele aufregende Lernmöglichkeiten,Forschung und Denken. Was für eine wunderbare Situation! Das Ende ist nicht nur nicht in Sicht, das Tempo lässt auch nicht nach. Wir haben viele zukünftige Freuden. "Ich stimme definitiv zu.

Originalbeitrag verfügbar unter //marxsoftware.blogspot.com/ (Inspiriert von tatsächlichen Ereignissen)

Diese Geschichte, "Buchbesprechung: Der mythische Mann-Monat: Essays on Software Engineering, Jubiläumsausgabe", wurde ursprünglich von JavaWorld veröffentlicht.