STP074: Literatur: Vom Mythos des Mann-Monats, Teil 2

<p>Beim letzten Mal war zuviel Buch für zu wenig Zeit übrig. Daher nun die Fortsetzung mit zwar gelegentlich etwas angestaubten, im Großen und Ganzen aber sinnvollen, Vorschlägen zur Organisation von Softwareentwicklung.</p><h2>Shownotes</h2>Fortsetzung aus STP068. Wir lesen weiterhin die englische Erstausgabe von 1975, die <a href="archive.org/details/MythicalManMonth">im Internet Archive</a> digitalisiert wurde.</p>
<h3>Kapitel 4: Aristokratie, Demokratie und System-Design</h3>
<ul>
<li>
<p>Brooks beschreibt als Leitmotiv die Kathedrale von Reims, die von acht Generationen von Baumeistern errichtet wurde, aber trotzdem eine beachtliche gestalterische Kohärenz aufweist, da die nachfolgenden Generationen das ursprüngliche Design ungewöhnlich stark respektieren: "Das Ergebnis verkündet nicht nur die Herrlichkeit Gottes, sondern auch seine Macht, gefallene Menschen von ihrem Stolz zu befreien."</p>
<ul>
<li>Kontrast nicht nur zu den meisten anderen Kirchenbauten, sondern auch zu Programmsystemen</li>
<li>dort aber nicht wegen Mehrgenerationalität, sondern wegen Vielstimmigkeit</li>
<li>These: konzeptionelle Integrität ist die wichtigste Eigenschaft im System-Design (vgl. STP006: Unix-Philosophie)</li>
<li>Vorteil: bessere Verwendbarkeit und Erlernbarkeit</li>
<li>Umsetzung: das Design sollte von einigen wenigen Architekten kontrolliert werden, die im Interesse des Benutzers handeln; doch hieraus drei Problemstellungen</li>
</ul>
</li>
<li>
<p>Problem 1: Folgt hieraus nicht eine aristokratische Klassengesellschaft von wenigen Vordenkern und bauendem Fußvolk?</p>
<ul>
<li>nein, auch auf der Implementationsebene gibt es viele interessante Entscheidungen zu treffen
<ul>
<li>Brooks zitiert einen Aphorismus aus der Kunst: "Form befreit.", sprich: Kreativität erwächst aus dem Umgang mit Beschränkungen</li>
</ul>
</li>
<li>in der Architektur geht es darum, was man dem Nutzer präsentiert (das "Was")</li>
<li>in der Bauphase geht es darum, wie man dieses Verhalten erreicht (das "Wie")</li>
<li>es ist absolut gewollt, dass die Erbauer auch Designideen vorschlagen und auf Beschränkungen hinweisen; nur entscheiden sie nicht final über das Design</li>
</ul>
</li>
<li>
<p>Problem 2: Wie verhindert man, dass die Architekten von den Zwängen der Realität abgekoppelt im Elfenbeinturm davonschweben?</p>
<ul>
<li>Xyrill bringt eines seiner Lieblings-Schimpfwörter ins Spiel: <a href="en.wikipedia.org/w/index.php?title=Architectur…;
<li>Lösung dieselbe wie für das dritte Problem</li>
</ul>
</li>
<li>
<p>Problem 3: Wie stellt man sicher, dass die Erbauer mit allen wichtigen Details des Designs vertraut gemacht werden?</p>
<ul>
<li>Lösung: die Erbauer frühzeitig in den Design-Prozess involvieren, Ideen aufnehmen, Designvorschläge auf praktische Umsetzbarkeit abklopfen etc.</li>
<li>Vergleich mit der Errichtung eines Gebäudes: man kann die Erbauer nicht erst einstellen, wenn der Plan fertig ist, weil in der Software-Entwicklung immer noch vieles explorativ und nicht nach Standard-Muster abläuft</li>
</ul>
</li>
</ul>
<h3>Kapitel 5: Das Problem des zweiten Systems ("Second-System Effect")</h3>
<ul>
<li>
<p>in diesem Dialog zwischen Architekt und Erbauer stellen sich viele Ideen des Architekten als unpraktikabel heraus und werden verworfen... bis zum nächsten Mal</p>
<ul>
<li>Szenario: das erste System war erfolgreich, der Architekt hat Prestige und Erfahrung gewonnen</li>
<li>"Dieses zweite ist das gefährlichste System, dass man jemals entwirft." -> <a href="en.wikipedia.org/w/index.php?title=Second-syst… Effect</a></li>
<li>beim dritten und vierten System hat man dann mehr Erfahrung, was tatsächlich funktioniert und was nur auf dem Papier gut aussieht</li>
<li>Xyrill legt Wert darauf, dass seine jüngeren Kollegen früh ihre eigenen Komponenten alleine entwerfen, damit sie dann auch in die Probleme ihrer eigenen Design-Entscheidungen reinlaufen und daraus lernen</li>
</ul>
</li>
<li>
<p>der vorgeschlagene Lösungsansatz ist leider etwas antiquiert: "Eine Disziplin, die dem Architekten die Augen öffnen wird, ist es, jeder kleinen Funktion einen Wert zuzuweisen: Fähigkeit X ist nicht mehr wert als M Bytes Speicher und N Mikrosekunden pro Aufruf. Diese Werte dienen als Richtschnur für die ersten Entscheidungen und während der Implementierung als Leitfaden und Warnung an alle."</p>
<ul>
<li>nicht realisitisch in Zeiten, wo die meisten Programmierer offenkundigerweise noch nie einen Profiler verwendet haben oder auch nur ein Gefühl für ihre eigene Ressourcenvergeudung haben</li>
</ul>
</li>
</ul>
<h3>Kapitel 6: Weitergabe von Informationen ("Passing the Word")</h3>
<ul>
<li>
<p>Wie stellt eine Gruppe von 10 Architekten sicher, dass ihre Entwürfe von 1000 Mitarbeitenden berücksichtigt und von allen Benutzern verstanden werden?</p>
<ul>
<li>gute Dokumentation ist erforderlich: Handbücher für die Benutzer, Architekturpläne für die Erbauer</li>
</ul>
</li>
<li>
<p>Qualitäten guter Dokumentation</p>
<ul>
<li>vorzugsweise aus der Feder von nur ein oder zwei Personen -> Fokus auf konzeptionelle Integrität</li>
<li>Beschreibung sowohl des definierten Verhaltens als auch der Grenzen der Definiertheit</li>
<li>Definitionen in formaler Notation und/oder präziser Sprache, um Lücken und Widersprüche im Design möglichst früh aufzudecken</li>
<li><a href="de.wikipedia.org/w/index.php?title=Anti-Patter…;: Definition eines Systems durch sein eigenes Verhalten
<ul>
<li>führt zu Bug-für-Bug-Kompatibilität (siehe STP050) bzw. Ossifikation (siehe STP056): inhaltliche Widersprüche zwischen der ursprünglichen Implementation, späteren Revisionen sowie später abgeleiteten Spezifikationen</li>
</ul>
</li>
<li>gutes Pattern: Spezifikation maschinenlesbar darstellen, damit die Erbauer die Konformität ihrer Implementation mit der Spezifikation automatisch prüfen können
<ul>
<li>aktuelles Beispiel: formale Spezifikation von Schnittstellen mittels <a href="de.wikipedia.org/w/index.php?title=OpenAPI&…;
</ul>
</li>
</ul>
</li>
<li>
<p>Wie erarbeitet man Designs? Vorschlag von Brooks:</p>
<ul>
<li>Meetings zwischen den Architekten und involvierten Erbauern, in denen das Problem vorgestellt und mehrere Designideen gesammelt werden</li>
<li>dann Erarbeitung von detaillierten Designentwürfen mit Pro-/Kontra-Analyse</li>
<li>daraus entweder sofortiger Konsens oder Entscheidung eines Chefarchitekten</li>
<li>klingt offensichtlich, ist aber im <a href="de.wikipedia.org/w/index.php?title=Agile_Softw… Zeitalter</a> selten anzutreffen</li>
</ul>
</li>
<li>
<p>noch eine kleine Anmerkung am Rande: auch Kurzabsprachen am Telefon sollten dokumentiert werden :)</p>
</li>
</ul>
<h3>Kapitel 7: Warum ist der Turm zu Babel gefallen?</h3>
<ul>
<li>
<p>Woran können Projekte scheitern?</p>
<ul>
<li>unklare Zielstellung</li>
<li>nicht genug Personal</li>
<li>nicht genug Material/Budget</li>
<li>nicht genug Zeit</li>
<li>unzureichende Technologien</li>
<li><em>ineffektive Kommunikation</em></li>
</ul>
</li>
<li>
<p>Wie sollen Teams kommunizieren? Neben direkten Gesprächen z.B. via Telefon und Gruppengesprächen z.B. in Meetings wird ein <strong>Arbeitsbuch</strong> vorgeschlagen.</p>
<ul>
<li>nicht ein konkretes Dokument, sondern eine Struktur für alle Dokumente im Projekt</li>
<li>die Dokumentation am Ende geht aus den Memos am Anfang hervor, also gleich richtig machen</li>
<li>Memos sollen durchnummeriert werden, damit man später darauf Bezug nehmen kann (wir fühlen uns an RFCs erinnert) -> Arbeitsbuch ergibt sich als Baumstruktur aller Memos (wir fühlen uns an Hypertext erinnert, und in der Tat wird Douglas C. Engelbart am Rande erwähnt)</li>
<li>Brooks diskutiert dann praktische Unterschiede zwischen Papier und Microfiche, die heutzutage keine Relevanz mehr haben (aber ein Nachteil: die …