STP068: Literatur: Vom Mythos des Mann-Monats

<p>In dieser Episode wird ein lang gehegter Traum wahr. Xyrill hat ein Buch gelesen und spricht darüber. Obwohl es nicht sehr dick ist, ist es doch sehr gehaltvoll und so entscheiden wir uns kurz vor Ende der Sendung für eine spontane Planänderung.</p><h2>Shownotes</h2>Wir lesen die englische Erstausgabe von 1975, die <a href="archive.org/details/MythicalManMonth">im Internet Archive</a> digitalisiert wurde.</p>
<ul>
<li>zum Autor: <a href="de.wikipedia.org/w/index.php?title=Frederick_P… P. Brooks, Jr.</a> (US-amerikanischer Informatiker, 1931-2022)
<ul>
<li>in den 60ern Entwicklungsleiter bei IBM für das Betriebssystem OS/360 (eines der ersten Systeme mit Unterstützung für persistente Massenspeicher mit Wahlzugriff, sprich: Festplatten)</li>
<li>gilt als Erfinder des Bytes mit 8 Bit; Wikipedia zitiert Brooks aus einem Interview von 2010:</li>
</ul>
</li>
</ul>
<blockquote>
<p>„Die wichtigste Entscheidung, die ich je getroffen habe, war, die IBM-360-Serie von einem 6-Bit-Byte auf ein 8-Bit-Byte umzustellen und damit die Verwendung von Kleinbuchstaben zu ermöglichen. Diese Veränderung verbreitete sich überall.“</p>
</blockquote>
<ul>
<li>
<p>zum Buch: "Vom Mythos des Mann-Monats" ("The Mythical Man-Month") dokumentiert Brooks' Erfahrungen als Projekt-Manager in einem der frühen großen Software-Projekte</p>
<ul>
<li>nicht als Lehrbuch angelegt, weil es dafür "noch zu früh" gewesen sei, sondern als Serie persönlicher Eindrücke und Lektionen</li>
<li>fast jedes Kapitel ist ein alleinstehendes Essay</li>
<li>wir wollen schauen, ob diese Lektionen auch heute noch Bestand haben</li>
<li>in der ersten Hälfte des Buches (Kapitel 2-7) ist das übergreifende Motiv, wie sich die Arbeit in großen Teams von kleinen Teams unterscheidet</li>
</ul>
</li>
<li>
<p>Hörempfehlung: <a href="c3d2.de/news/pentaradio24-20221227.html"&… vom Dezember 2022</a></p>
<ul>
<li>anlässlich Brooks' Tod hatten wir über seinen anderen wichtigen Text "No Silver Bullet" und das Thema Komplexität gesprochen</li>
</ul>
</li>
</ul>
<h3>Kapitel 1: Die Teergrube</h3>
<ul>
<li>
<p>Teergruben-Analogie: steckt ein Tier mit einem Bein in der Teergrube, kann es das Bein meist aus eigener Kraft herausziehen; alle Beine in der Teergrube sind hingegen meist ein Todesurteil</p>
<ul>
<li>analog hierzu: Zähheit/Trägheit in der Software-Entwicklung nicht aus einem bestimmten Grund, sondern aufgrund mehrerer parallel wirkender Gründe</li>
</ul>
</li>
<li>
<p>Programme können von Einzelpersonen oder Zweierteams erschaffen werden</p>
<ul>
<li>These: aber nicht "Programmsystemprodukte"</li>
</ul>
</li>
<li>
<p>vom Programm zum Programmprodukt: Generalisierung (Nützlichkeit für eine ganze Klasse von Situationen), Testabdeckung (siehe STP038), Dokumentation, fortlaufende Wartung -> heute sagt man "Produktisierung" dazu</p>
<ul>
<li>Brooks schätzt hier dreimal mehr Aufwand als für das reine Programm</li>
<li>Xyrill würde heute sogar einen größeren Faktor schätzen, vllt. 4 oder 5: im Bereich der Programmierproduktivität gab es mehr Innovationen beim initialen Schreiben als bei Maintenance (siehe Xyrills Kritik an Ruby als einzeilerorientiert; siehe auch LLMs, aber das verschiebt sich eventuell gerade)</li>
<li>Parallele zu "warum setzt sich Open Source nicht durch", siehe Besprechnung von <a href="berthub.eu/articles/posts/open-source-by-itsel… Source on its own is no alternative to Big Tech"</a> im <a href="c3d2.de/news/pentaradio24-20241224.html"&… vom Dezember 2024</a></li>
</ul>
</li>
<li>
<p>vom Programm zum Programmsystem: Einbettung in ein Netzwerk anderer Programme mit konsistentem Stil und definierten Schnittstellen untereinander</p>
<ul>
<li>Brooks legt hier auch Wert auf ein vordefiniertes Ressourcenbudget (CPU-Zeit, Speicher, Datenverkehr) für jedes Teilprogramm -> heute überholt; Effizienz der Belegschaft geht über Effizienz des Produktes</li>
<li>Brooks schätzt hier <em>mindestens</em> dreimal mehr Aufwand als für die reinen Programme</li>
<li>Xyrill stimmt im Großen und Ganzen zu: heute zwar öfter von Anfang an wohlgeformte Schnittstellen (vgl. Unix-Philosophie in STP006, JSON in STP071), aber andererseits gestiegene Gesamtkomplexität</li>
</ul>
</li>
<li>
<p>Programmsystemprodukt: ein produktisiertes Programmsystem</p>
<ul>
<li>somit laut Brooks' Schätzung <code>3 x 3 = 9</code> Mal mehr Aufwand als für die einzelnen Programme</li>
</ul>
</li>
</ul>
<h3>Kapitel 2: Vom Mythos des Mann-Monats</h3>
<ul>
<li>
<p>Problem 1: Programmierer sind schlecht im Schätzen von Zeitaufwand</p>
<ul>
<li>inhärenter Optimismus: für jede Teilaufgabe schätzt man den Aufwand im Fall, dass alles gut geht</li>
<li>These: das Programm entsteht erst im Kopf und dann in der Realität; letzteres dauert länger, aber ein Programm, dass im Kopf fertig ist, fühlt sich schon fertig an</li>
<li>Programme sind kristallisierte Gedanken auf eine sehr viel direktere Art und Weise als z.B. Handwerksstücke, die kategorisch in ein physisches Artefakt umgesetzt werden müssen</li>
<li>Testphasen sind von diesem Optimismus am stärksten betroffen
<ul>
<li>Xyrill stimmt im Prinzip zu; allerdings wird heute versucht, Tests bei der Entwicklung einzugliedern (siehe Besprechung von TDD in STP038)</li>
</ul>
</li>
</ul>
</li>
<li>
<p>Problem 2: konventielle Planungsmethoden funktionieren nur, wenn "Personen und Monate austauschbar sind"</p>
<ul>
<li>Basiseinheit: Mann-Monat (heute sagt man Personenmonat); die Menge Arbeit, die eine Person in einem Monat verrichten kann</li>
<li>Messung von Aufwand in Personenmonaten impliziert, dass eine Aufgabe unter mehreren Personen aufgeteilt werden kann und keine Kommunikation zwischen diesen Personen erforderlich ist
<ul>
<li>kommt hin für z.B. Spargelstechen oder Zimmerreinigung im Hotel, aber: "Das Austragen eines Kindes dauert neun Monate, egal, wieviele Frauen der Aufgabe zugewiesen werden."</li>
</ul>
</li>
<li>zwei Komplikationen: Einarbeitungszeit (linear in der Größe des Personals) und fortwährender Kommunikationsaufwand (quadratisch in der Größe des Personals)
<ul>
<li>Xyrill kann das 100-%-ig bestätigen; in großen Teams verbringen die hochrangigen Techniker signifikant mehr Zeit mit Meetings/Mails/Chat als mit ihrer nominalen Tätigkeit</li>
<li>quadratisches Wachstum kann teilweise begrenzt werden durch Einführung von Unterteams mit strikten Rollenverteilungen; dann tritt das <a href="de.wikipedia.org/w/index.php?title=Gesetz_von_… von Conway</a> in Kraft</li>
</ul>
</li>
</ul>
</li>
<li>
<p>Problem 3: der Zeitplan wird durch die Bedürfnisse des Kunden bestimmt, nicht durch die Bedürfnisse der Programmierer</p>
<ul>
<li>Restaurant-Analogie: wenn man das langsam gegarte Steak in nur 5 Minuten haben will, wird der Koch sich dem entgegenstellen... oder er dreht halt die Hitze hoch und man kriegt ein schlechteres Produkt</li>
<li>Programmierprojekte richten sich aber oft dem vom Kunden und/oder Management vorgegebenen Liefertermin: "Es ist sehr schwierig, eine Schätzung energisch, plausibel und arbeitsplatzgefährdend zu verteidigen, die auf keiner quantitativen Methode beruht, durch wenig Daten gestützt und hauptsächlich durch das Bauchgefühl der Manager getragen wird."</li>
<li>wenn dann beim Testen am Ende eine Verspätung eintritt, ist die Versuchung groß, halb fertige Produkte zu liefern (vgl. "Bananaware")</li>
</ul>
</li>
<li>
<p>Problem 4: Was macht man, wenn dann das Kind in den Brunnen gefallen ist und man zu spät dran ist?</p>
<ul>
<li>Option 1: Lieferdatum nach hinten verschieben</li>
<li>Option 2: Umfang reduzieren
<ul>
<li>passiert eventuell auch unter der Hand, zum Beispiel indem beim Design und beim Testen Arbeitstempo gegen Sorgfalt abgewogen wird</li>
<li>Xyrill schielt auf sein ständig wachsendes Backlog an "müsste man mal machen"-Aufgaben</li>
</ul>
</li>
<li>Option 3: weitere Leute hinzufügen
<ul>
<li><a …