Podcast Episode Details

Back to Podcast Episodes

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


Season 1 Episode 74


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.

Shownotes

Fortsetzung aus STP068. Wir lesen weiterhin die englische Erstausgabe von 1975, die im Internet Archive digitalisiert wurde.

Kapitel 4: Aristokratie, Demokratie und System-Design

  • 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."

    • Kontrast nicht nur zu den meisten anderen Kirchenbauten, sondern auch zu Programmsystemen
    • dort aber nicht wegen Mehrgenerationalität, sondern wegen Vielstimmigkeit
    • These: konzeptionelle Integrität ist die wichtigste Eigenschaft im System-Design (vgl. STP006: Unix-Philosophie)
    • Vorteil: bessere Verwendbarkeit und Erlernbarkeit
    • Umsetzung: das Design sollte von einigen wenigen Architekten kontrolliert werden, die im Interesse des Benutzers handeln; doch hieraus drei Problemstellungen
  • Problem 1: Folgt hieraus nicht eine aristokratische Klassengesellschaft von wenigen Vordenkern und bauendem Fußvolk?

    • nein, auch auf der Implementationsebene gibt es viele interessante Entscheidungen zu treffen
      • Brooks zitiert einen Aphorismus aus der Kunst: "Form befreit.", sprich: Kreativität erwächst aus dem Umgang mit Beschränkungen
    • in der Architektur geht es darum, was man dem Nutzer präsentiert (das "Was")
    • in der Bauphase geht es darum, wie man dieses Verhalten erreicht (das "Wie")
    • es ist absolut gewollt, dass die Erbauer auch Designideen vorschlagen und auf Beschränkungen hinweisen; nur entscheiden sie nicht final über das Design
  • Problem 2: Wie verhindert man, dass die Architekten von den Zwängen der Realität abgekoppelt im Elfenbeinturm davonschweben?

    • Xyrill bringt eines seiner Lieblings-Schimpfwörter ins Spiel: "Architektur-Astronaut"
    • Lösung dieselbe wie für das dritte Problem
  • Problem 3: Wie stellt man sicher, dass die Erbauer mit allen wichtigen Details des Designs vertraut gemacht werden?

    • Lösung: die Erbauer frühzeitig in den Design-Prozess involvieren, Ideen aufnehmen, Designvorschläge auf praktische Umsetzbarkeit abklopfen etc.
    • 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

Kapitel 5: Das Problem des zweiten Systems ("Second-System Effect")

  • in diesem Dialog zwischen Architekt und Erbauer stellen sich viele Ideen des Architekten als unpraktikabel heraus und werden verworfen... bis zum nächsten Mal

    • Szenario: das erste System war erfolgreich, der Architekt hat Prestige und Erfahrung gewonnen
    • "Dieses zweite ist das gefährlichste System, dass man jemals entwirft." -> Second-System Effect
    • beim dritten und vierten System hat man dann mehr Erfahrung, was tatsächlich funktioniert und was nur auf dem Papier gut aussieht
    • 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


      Published on 2 months, 3 weeks ago






If you like Podbriefly.com, please consider donating to support the ongoing development.

Donate