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.
ShownotesFortsetzung 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."
Problem 1: Folgt hieraus nicht eine aristokratische Klassengesellschaft von wenigen Vordenkern und bauendem Fußvolk?
Problem 2: Wie verhindert man, dass die Architekten von den Zwängen der Realität abgekoppelt im Elfenbeinturm davonschweben?
Problem 3: Wie stellt man sicher, dass die Erbauer mit allen wichtigen Details des Designs vertraut gemacht werden?
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
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."
Kapitel 6: Weitergabe von Informationen ("Passing the Word")
Wie stellt eine Gruppe von 10 Architekten sicher, dass ihre Entwürfe von 1000 Mitarbeitenden berücksichtigt und von allen Benutzern verstanden werden?
Qualitäten guter Dokumentation
Wie erarbeitet man Designs? Vorschlag von Brooks:
noch eine kleine Anmerkung am Rande: auch Kurzabsprachen am Telefon sollten dokumentiert werden :)
Kapitel 7: Warum ist der Turm zu Babel gefallen?
Woran können Projekte scheitern?
Wie sollen Teams kommunizieren? Neben direkten Gesprächen z.B. via Telefon und Gruppengesprächen z.B. in Meetings wird ein Arbeitsbuch vorgeschlagen.
D. L. Parnas von der Carnegie-Mellon-Universität hat eine noch radikalere Lösung vorgeschlagen. Seine These lautet, dass ein Programmierer am effektivsten ist, wenn er von den Details der Konstruktion von Systemteilen, die nicht seine eigenen sind, abgeschirmt wird, anstatt ihnen ausgesetzt zu sein. Dies setzt voraus, dass alle Schnittstellen vollständig und genau definiert sind. Dies ist zwar ein solider Entwurf, aber in der Abhängigkeit von seiner perfekten Ausführung ist eine Katastrophe vorprogrammiert. Ein gutes Informationssystem deckt Schnittstellenfehler auf und regt zu deren Korrektur an.
Xyrill stimmt voll und ganz zu: sorgfältiges Gegenlesen der Meeting-Minutes der benachbarten Teams ist zwar extrem zeitaufwändig, verhindert aber regelmäßig katastrophale Design-Entscheidungen
Organisationsstruktur: Brooks hält eine baumförmige Organisationsstruktur für unausweichlich (mehrere Vorgesetzte für einen Angestellten = Chaos) und schaut darauf, was jedes Team haben sollte
Option 1: Produzent und Architekt sind dieselbe Person
Option 2: Produzent als Chef, Architekt als seine rechte Hand
Option 3: Architekt als Chef, Produzent als seine rechte Hand
Noch mehr
Es gibt noch acht weitere Kapitel, die wir irgendwann™ mal besprechen werden.
