Auf das Buch “Righthing Software. A Method for System and Project Design” von Juval Löwy bin ich über seinen Podcastauftritt im Software Engineering Radio gestoßen. Da es leider schon fast zwei Jahre her ist, dass die Episode herauskam, das Buch erst einige Zeit auf meiner Wunschliste verbrachte und anschließend noch mal genau so lang auf’s gelesen werden wartete, bekomme ich die Motivation leider nicht mehr zusammen.

Der Titel kommt nach meinem Empfinden recht breitbeinig daher. Der Verlag schreibt zum Buch:

Based on first principles in software engineering and a comprehensive set of matching tools and techniques, Löwy’s methodology integrates system design and project design. First, he describes the primary area where many software architects fail and shows how to decompose a system into smaller building blocks or services, based on volatility. Next, he shows how to flow an effective project design from the system design; how to accurately calculate the project duration, cost, and risk; and how to devise multiple execution options.

Während ich die Analyse teile, dass Softwareprojekte zu oft fehlschlagen. Würde ich mir nicht anmaßen, eine Lösung dafür zu haben. Die erste große Überraschung mit dem Buch habe ich erlebt, als ich festgestellt habe, dass von den 390 Seiten nur drittel über Softwaredesign geht und der Rest sich wirklich um Software-Projektmanagement dreht. Während ich mit dem zweiten Teil nicht wirklich gerechnet hatte in der Tiefe, waren hier einige interessante Gedankengänge enthalten, die aber hauptsächlich für große Projekte mit mehreren Entwicklern und entsprechenden Abhängigkeiten operieren. Diese Art Projekt habe ich aktuell nicht. So blieb es eine Auffrischung von Themen, die ich im Studium gelernt habe. Die Bestimmung des kritischen Pfads hätte ich zwar so noch hinbekommen, aber dass es in der Praxis meistens effektiv weniger ausmacht mit der optimalen Entwicklerzahl zu jeder Zeit zu arbeiten, weil sich die Gesamtprojektlaufzeit bei einer gleichmäßigeren Anzahl Entwickler in der Regel nicht dramatisch verändert. Auch der Hinweis, dass Zeitersparnisse in der Gesamtprojektlaufzeit oft durch Fixkostenersparnisse auch höhere flexible Kosten ermöglichen, hätte ich so aus dem Stehgreif nicht gewusst (aber in der Planung eines Projektes hoffentlich bemerkt).

Aber deshalb habe ich das Buch ja nicht gekauft. Mich interessierte eigentich der Teil zum Softwaredesign und hier finde ich das Buch eine herbe Enttäuschung. Löwy nennt seinen Design-Ansatz einfach “The Method”. Ich vermute fast, dass das daran liegt, weil er selbst nicht in der Lage ist, sie klarer zu benennen. Immerhin sagt er, dass er weder eine fachliche Aufteilung noch eine funktionale Aufteilung für sinnvoll hält. Stattdessen sollte man die Software nach Änderungshäufigkeit aufteilen. In den Beispielen wird dann meistens eine klassische Schichtenarchitektur gezeigt mit Cross-Cutting-Functions (Logging, Messaging) über alle Schichten hinweg.

Ich habe zu dem Buch leider wenig gelesen bisher, evtl. habe ich es ja nur falsch verstanden. Ich würde mich über andere Meinungen freuen, immerhin sagen die Amazon-Bewertungen ja durchaus auch positives. Meine Vermutung ist, dass es eben an der Schnittstelle zwischen Design und Projektmanagement liegt, die sonst immer zu kurz kommt. Wer hier Erfahrungen hat, erreicht mich per Twitter oder E-Mail.

Wer jetzt noch Lust auf das Buch hat, bekommt es direkt beim O’Reilly.