Als letzten Streich in der Besprechung dieses Werkes hört ihr einen Mitschnitt von den Datenspuren von 2025-09-19; und da wir leider nicht den ganzen Rest des Buches in unsere Bühnenzeit bekommen haben, auch noch den Rest in der gewohnten Form. Applaus für den Presenter!

Shownotes

Fortsetzung aus STP068 und STP074. Wir lesen weiterhin die englische Erstausgabe von 1975, die im Internet Archive digitalisiert wurde.
Erneut als Vorbemerkung: Aus Quellentreue sagen wir "Mann-Monat" statt "Person-Monat".

Kurzzusammenfassung der bisherigen Folgen

Für die Zuschauer im Saal, die die vergangenen Folgen nicht gehört haben. Das übergreifende Motiv in dieser ersten Hälfte des Buches ist, wie sich die Arbeit in großen Teams von kleinen Teams unterscheidet.

1. Die Teergrube
   

   
   

   So wie man in der Teergrube erst gefangen ist, wenn alle Beine drinstecken, so resultiert die Trägheit von Software-Entwicklung aus einem Zusammenspiel mehrerer Faktoren. Ein Programm zu schreiben, ist einfach. Aber die Produktisierung erfordert viel mehr Aufwand: für Generalisierung, Testabdeckung, Dokumentation und fortlaufende Wartung. Außerdem muss sich das Programm in ein größeres System einfügen. Vom Programm zum Programmsystemprodukt erhöht sich der Aufwand um ungefähr eine ganze Größenordnung.

   
   

   
   


2. Vom Mythos des Mann-Monats
   

   
   

   Konventionelle Planungsmethoden funktionieren nur, wenn Personen und Monate austauschbar sind. Das beachtet jedoch weder die unterschiedlichen Kompetenzniveaus verschiedener Teammitglieder noch den zusätzlichen Zeitaufwand durch Kommunikation innerhalb des Teams sowie zwischen Teams. Da Programmierer aber schlecht im Schätzen von Zeitaufwand sind, wird in der Praxis der Zeitplan oft an den Bedürfnissen der Kunden ausgerichtet, nicht an den technischen Randbedingungen. Wenn dann das Kind in den Brunnen gefallen ist, tritt das Brooks'sche Gesetz in Kraft: "Das Hinzufügen weiteren Personals zu einem verspäteten Softwareprojekt verspätet es weiter."

   
   

   
   


3. Das OP-Team
   

   
   

   Um die Kommunikationskosten zu verringern, stellt Brooks ein Modell für kleinere Teams vor, die in Analogie zu einem OP-Team organisiert sind, in dem immer nur einer auf einmal die eigentliche Programmierarbeit leistet und alle anderen nur zuarbeiten. Die genaue Beschreibung ist sicherlich überholt: Heutzutage braucht man zum Beispiel keinen Schreiber mehr, der Lochkarten sortiert. Aber vielleicht haben wir auch etwas verloren, als wir Sekretärsrollen ersetzt haben dadurch, dass jetzt die rare Expertin Termine im Outlook schubsen und Präsentationsfolien zusammenklicken muss.

   
   

   
   


4. Aristokratie, Demokratie und System-Design
   

   
   

   Die Kathedrale von Reims wurde von acht Generationen von Baumeistern errichtet, weist aber trotzdem eine beachtliche gestalterische Kohärenz auf, weil die nachfolgenden Generationen das ursprüngliche Design respektiert haben. Daraus muss aber nicht folgen, dass ein einzelner Architekt alle Entscheidungen trifft und die Erbauer nur stupide die Pläne umsetzen. Auch auf der Umsetzungsebene gibt es viele interessante Designentscheidungen zu treffen; und ein guter Architekt hört auch auf seine Erbauer, wenn es um Fragen von Praktikabilität geht.

   
   

   
   


5. Das Problem des zweiten Systems
   

   
   

   In diesem Dialog zwischen Architekt und Erbauer stellen sich also oftmals Ideen des Architekten als unpraktikabel heraus und werden verworfen. Doch wenn das erste System erfolgreich war, gewinnt der Architekt an Prestige und Erfahrung, die dazu verleiten kann, beim nächsten Mal alle Sachzwänge zu ignorieren. Ein weiteres klassisches Diktum von Brooks ist deswegen: "Dieses zweite ist das gefährlichste System, dass man jemals entwirft."

   
   

   
   


6. Weitergabe von Informationen
   

   
   

   Damit ein Entwurf von 10 Architekt:innen von 1000 Mitarbeiter:innen und nochmal deutlich mehr Nutzer:innen verstanden wird, braucht es gute Dokumentation: Handbücher für Benutzer, und Architekturpläne für Erbauer. Brooks schlägt hier einiges vor, was heute in der Industrie gelebte Praxis ist (oder zumindest sein sollte), zum Beispiel maschinenlesbare Spezifikation von Schnittstellen und automatisierte Tests zur Überprüfung der Kompatibilität. Sein Ruf nach sorgfältiger Pro/Kontra-Abwägung zwischen mehreren möglichen Design-Optionen verhallt im Zeitalter agiler Softwareentwicklung jedoch oftmals ungehört.

   
   

   
   


7. Warum ist der Turm zu Babel gefallen?
   

   
   

   Offensichtlich ist ineffektive Kommunikation einer der wesentlichen Gründe dafür, dass Software-Großprojekte scheitern oder erst mit deutlicher Verspätung liefern. Somit stellt sich die Frage nach der optimalen Teamstruktur in einer Software-Entwicklungsabteilung. Brooks hält eine baumförmige Struktur für unausweichlich, damit Entscheidungskompetenzen klar geregelt sind. In jedem Entwicklungsteam sollte es sollte es neben einem Architekten (dem Chefentwickler des Teams) auch einen Produzenten geben, der sich um die Kommunikation mit anderen Teams kümmert. Da eine Personalunion zwischen beiden Rollen nicht skaliert, muss entweder der Architekt der Chef des Produzenten sein: Dies passt aber nicht zu den separaten Management-Karrieren in den großen Firmen. Oder der Produzent ist der Chef des Architekten: Dies kann aber nur funktionieren, wenn der Produzent die technische Autorität des Architekten akzeptiert.

   
   

   
   

Kapitel 8: "Calling the Shot"

• 
  

  "Calling the Shot" hier im Baseball-Sinne: vorher ansagen, wo der Ball nach dem Schlag landet

  
  
  
  
  • Wie lange wird eine System-Programmierungsaufgabe dauern? Wieviel Aufwand ist nötig? Wie schätzt man das?
  
  
  
  


• 
  

  Problem: Code schreiben alleine ist noch einigermaßen abschätzbar, macht aber nur einen kleinen Teil (vllt. ein Sechstel) des Gesamtaufwandes aus

  
  
  
  
  • Aufwand steigt exponentiell mit der Komplexität des Programmiersystems, weil Interaktionen zwischen verschiedenen Teilen des Systems beachtet werden müssen und Kompromisse im Design erfordern (vgl. Kapitel 1)
  
  
  • und dann zusätzlicher Overhead, sobald Kommunikation zwischen mehreren Teammitgliedern erforderlich ist (vgl. Kapitel 2)
  
  
  
  


• 
  

  Brooks fasst dann Erkenntnisse aus mehreren quantitativen Studien zusammen; Highlights:

  
  
  
  
  • Geschwindigkeitsschätzungen waren zu Beginn immer ziemlich akkurat, aber im Verlauf des Projektes wird mit zunehmender Komplexität alles immer träger
  
  
  • Aufwand scheint am stärksten von der Gesamtmenge an Code abzuhängen (sprich: 1000 Zeilen Code sind ähnlicher Aufwand, unabhängig von der Sprache) -> Überleitung in das nächste Kapitel
  
  
  
  

Kapitel 9: Zehn Pfund in einem Fünf-Pfund-Sack

• 
  

  wenn Code kein Wert an sich, sondern eine Verbindlichkeit ist, wie kann man Code reduzieren?

  
  
  
  
  • Hochsprachen -> vgl. "No Silver Bullet" und intrinsiche vs. versehentliche Komplexität ("essential vs. accidental complexity"; besprochen im Pentaradio vom Dezember 2022)
  
  
  • Xyrill sieht einen Bezug zum Hype um Coding-KI und die damit verbundenen Werbeversprechen
  
  
  
  


• 
  

  Brooks zieht eine Parallele zu Hardware-Entwurf: "Weil die Größe ein wichtiger Teil der Benutzerkosten eines Programmiersystem-Produktes ist, muss der Erbauer Größenziele setzen, die Größe im Auge behalten, und Techniken zur Größenreduktion ersinnen; genau so, wie ein Hardware-Erbauer Komponentenzahlziele setzt, die Komponentenzahl im Auge behält, und Techniken zur Reduktion der Komponentenzahl ersinnt. Wie jede Art von Kosten ist Größe an sich nicht schlecht, aber überflüssige Größe ist es."

  
  
  
  
  • vgl. Kapitel 1 (siehe STP068), wo bereits ein vordefiniertes Ressourcenbudget für jedes Teilprogramm gefordert wurde
  
  
  • heute (leider?) nicht mehr en vogue; Speicher ist zu günstig geworden
  
  
  
  


• 
  

  "Repräsentation ist die Essenz des Programmierens": Brooks hält den Entwurf passender Datenstrukturen für sehr viel relevanter als die Auswahl passender Algorithmen

  
  
  
  
  • Xyrill stimmt offensichtlicherweise zu, siehe STP071/072
  
  
  • "Zeig mir deine Flussdiagramme ohne die [Datenbank-]Tabellen, und ich werde verwirrt bleiben. Zeig mir deine Tabellen, und ich werde die Flussdiagramme wahrscheinlich nicht brauchen; sie werden offensichtlich sein."
  
  
  • Xyrill vermutet, dass hierher seine tiefe Abneigung gegen Prozess-Designer rührt
  
  
  
  

Kapitel 10: Die dokumentarische Hypothese

Die Hypothese: Verborgen in einem riesigen Papierhaufen verborgen, werden eine kleine Zahl von Dokumenten zu kritischen Angelpunkten, um die sich das Management eines jeden Projektes dreht. Dies sind die zentralen Werkzeuge eines Managers.

• 
  

  "Auf einen neuen Manager, der gerade aus dem Handwerk gewechselt ist, erscheint der meiste Papierkram als vollständiges Ärgernis, als unnütze Ablenkung, und eine weiße Flut, die droht, ihn zu umspülen. Und in der Tat sind die meisten dieser Dokumente genau das."

  
  
  
  
  • doch einige Dokumente sind essentiell und das wesentliche Arbeitsergebnis des Managers
  
  
  • Mindestsatz laut Brooks: Zielsetzungen/Spezifikationen, Zeitplan, Budget, Ressourcenzuteilung, Personalzuteilung (letzteres vgl. Conway's Gesetz: "Organisationen, die Systeme entwerfen, sind gezwungen, Systeme hervorzubringen, die die Kommunikationsstruktur dieser Organisation kopieren.")
  
  
  
  


• 
  

  wesentliche Funktionen von Dokumentation für den Manager:

  
  
  
  
  • Festhalten von Entscheidungen: Aufschreiben legt Widersprüche, Denkfehler und -lücken offen
  
  
  • Kommunizieren von Entscheidungen: Manager sind die meiste Zeit Ko