No Silver Bullet

Premature Optimization - noch einmal

Kurz nachdem ich meinen Blog-Eintrag Performance und die Ausrede der verfrühten Optimierung hier gepostet habe, erschien unter dem Titel "The Second Law of Optimization" ein lesenswerter Beitrag von Ashod Nakashian zum gleichen Thema.

Im Wesentlichen sagt auch Ashod, dass man wissen muss, wo und wann es sich lohnt, von vornherein zu optimieren und wo man dies besser unterlässt:

Ashods Schwerpunkt liegt weniger auf den Auswirkungen der Architektur (obwohl er diese auch erwähnt), als vielmehr auf der vernünftigen Entscheidung für geeignete Datenstrukturen und/oder Algorithmen für ein Problem. Ein Thema, das ich in meinem Posting nicht behandelt habe.

Ich empfehle, den ganzen Beitrag (oder doch zumindest Ashods eigene Zusammenfassung für Eilige) zu lesen, will aber zumindest ein Beispiel wiedergeben:

Gute Beispiele für sinnvolle Optimierungen, deren späterer Einbau mit dem dazugehörigen Umbau des restlichen Codes deutlich aufwendiger wäre, als dies gleich zu bedenken. Das ist ein wichtiger Aspekt, der in meinem Posting eindeutig zu kurz kam. Von unterschiedlichen Ausgangspunkten kommend, sind wir aber beide zu dem gleichen Schluss gekommen: Man muss wissen, wann es sich lohnt, rechtzeitig nachzudenken und wo man dies übertriebenen Ehrgeiz bedeutet:

Also es gilt weiterhin:

Know when to play dumb!   :-)

Gepostet am 29.06.2011 um 10:55  |  Kommentare[0]

Wieder zurück

Nach langer Pause habe ich letztes Wochenende erstmalig wieder einen Eintrag gepostet. Anfang letzten Jahres wurde unser Sohn Linus geboren und danach war meine Zeit logischerweise etwas knapp :-) Infolge dessen habe ich meine Mitarbeit bei GlassFish als auch meinem Blog erst mal ruhen lassen.

Linus beansprucht nach wie vor viel Zeit - und das auch völlig zu recht. Und es macht auch viel Spaß mit ihm. Doch inzwischen ist unser Tagesablauf wieder deutlich geordneter und somit will und kann ich die Postings wieder aufnehmen.

Dabei werde ich weiterhin schwerpunktmäßig über GlassFish posten und zudem den ein oder anderen Kommentar über den Stand der Software-Entwicklung, sinnlose Hypes und Management-Erwartungen einstreuen.

Und weil Technorati es so will, hier mein Claim Code: GS7UY9JSYM2W :-)

Gepostet am 08.06.2011 um 22:56  |  Kommentare[0]

FOSDEM 2008

Dieses Jahr war bereits meine vierte FOSDEM. Wie jedes Jahr fand das Free and Open Source Developers European Meeting auf dem Gelände der Université Libre de Bruxelles statt - und endlich einmal hat das Wetter mitgespielt, und man konnte sich auch außerhalb des Uni-Gebäudes aufhalten und mitunter sogar in der Sonne sitzen.

Wie immer fingen die Keynotes mit erheblicher Verspätung an, dafür folgten sie dann unterbrechungsfrei aufeinander. Das war nicht so ganz nach meinem Geschmack. Die erste Keynote über die Nutzung von Linux bei der Filmproduktion war zwar interessant, aber schwer anzuhören. Die zweite über das FreeBSD-Projekt war beeindruckend. Auch wenn ich Linux vorziehe, bin ich doch froh, dass mit den BSDs freie Alternativen existieren und diese offensichtlich auch weiterhin gut gedeihen.

Trotz dem gelungenen Vortrag brauchte ich danach einfach eine Pause und einen Kaffee. Außerdem gab es draußen belgische Pommes! Somit habe ich den Vortrag zum aktuellen Stand der Patent-Debatte verpasst, obwohl er mich von den Keynotes eigentlich am meisten interessiert hätte.

Das Wichtigste an der FOSDEM sind allerdings die Developer-Tracks. Bei meinen vorherigen FOSDEM-Besuchen hatte ich hauptsächlich die Tracks zu den freien Java-Implementierungen (2007 war dann auch SUN mit Vertretern des OpenJDK-Teams erstmalig mit dabei) besucht, doch diesmal standen für mich andere Themen an. Meine Themenschwerpunkte lagen auf den PostgreSQL- und OpenOffice-Vorträgen. PostgreSQL entwickelt sich in einem erfreulichen Tempo und in eine gute Richtung und wird sicher weiter an Bedeutung gewinnen.

Beim Vergleich der Vorträge des PostgreSQL- und des OpenOffice-Teams hatte ich den Eindruck, dass es den Postgres-Vortragenden eher gelang, neue Leute anzusprechen, als dem OpenOffice-Team. Aber letztere haben es mit ihrer Code-Basis auch sicher schwerer. Deutlich ist das Bemühen erkennbar, OpenOffice stärker zu modularisieren und die Einstiegshürde für Neue abzusenken. Die Extensions sind hier ein wichtiger Schritt in die richtige Richtung. Bis auch die Entwicklung am OO.o-Kern oder den einzelnen Anwendungen attraktiv wird, bleibt jedoch noch viel zu tun. Das OO.o-Team jedenfalls wirbt intensiv um neue Entwickler oder andere Projektbeteiligte und ist dabei, die derzeit existierenden Hürden für den Einstieg ins Projekt abzusenken. OpenOffice 3.0 wird hierbei ein weiterer wichtiger Meilenstein sein.

Fast schon eine Tradition ist mein Besuch von Robert Kaisers (a.k.a. KaiRo) Vortrag über den jeweils aktuellen Stand der Seamonkey-Entwicklung. Seamonkey ist der aus der Mozilla-Suite hervorgegangene Browser in seiner aktuellen Version. Er wird fleißig weiter entwickelt, und die Neuerungen für die Version sehen vielversprechend aus.

Für mich als schwerpunktmäßiger Webentwickler war Rogan Dawes' Vortrag über WebScarab NG besonders interessant. WebScarab ist etwas vereinfacht ein Tool zum Abfangen von Browser-Requests und Server-Antworten, um diese manipulieren zu können. Damit ist es somit zur Durchführung von Penetration-Tests geeignet. Diverse Plugins unterstützen einen dabei. Ein Tool, über das ich hier im Blog sicher noch ausführlicher schreiben werde.

Wie immer gibt es zwischendrin Lücken und dann wieder mehrere interessante Vorträge auf einmal. So habe ich leider den Globulation-Vortrag und den Beitrag "Hacking OpenOffice.org" nicht hören können.

Die FOSDEM war auch 2008 wieder den Besuch wert, und so werde ich nächstes Jahr sicher wieder dabei sein. Und das belgische Bier und die kulinarische Vielfalt Brüssels bilden zudem eine gute Grundlage für den abendlichen Ausgleich ;-)

Gepostet am 05.03.2008 um 23:12  |  Kommentare[0]

Warum "No Silver Bullet"?

Der Titel dieses Blogs ist eine Hommage an Fredericks P. Brooks. Bereits 1975 hat Brooks das Standardwerk "The Mythical Man-Month" geschrieben. Zwanzig Jahre später erschien eine Jubiläumsausgabe, die zusätzlich zum unveränderten Originaltext noch diverse Aufsätze Brooks' enthält. Einer davon ist der bereits 1987 in der Zeitschrift "Computer" der IEEE veröffentlichte Text "No Silver Bullet – Essence and Accident in Software Engineering". Trotz des für IT-Verhältnisse fortgeschrittenen Alters haben weder Brooks Buch noch der Aufsatz "No Silver Bullet" an Aktualität verloren. Ich kann nur jedem in der Software-Entwicklung Tätigen dieses Buch wärmstens empfehlen.

The Mythical Man-Month

Eine der Kernthesen Brooks im Buch "The Mythical Man-Month" ist, dass es ein fataler Fehler ist, Projekte, die bereits in Zeitverzug gekommen sind, durch zusätzliche Programmierer retten zu wollen:

Diese zentrale Aussage seines Buches bezeichnet Brooks selber als "Brooks's Law". Brooks argumentiert, dass das Einarbeiten neuer Projektbeteiligter, die Änderung der Aufgabenteilung und der erhöhte Kommunikationsbedarf durch mehr Projektbeteiligte jeden möglichen Nutzen der zusätzlichen Kräfte mehr als aufzehren. Brooks warnt allerdings nicht nur davor, dass ein unrealistischer Zeitplan durch mehr Kräfte kaum zu korrigieren ist, sondern kritisiert die Messgröße "Personenjahre" insgesamt und bezweifelt deren Aussagekraft:

Aber Menschen und Zeit sind nicht ohne Konsequenzen austauschbar. Der im Verhältnis zu den eingesetzten Kräften mehr als linear steigenden Kommunikationsaufwand, die individuellen Fähigkeiten der unterschiedlichen Kräfte, verlorenes Wissen durch abgezogene oder abgewanderte Mitarbeiter, der Einarbeitungsaufwand neuer Mitarbeiter und die nur bedingt gegebene Teilbarkeit der Aufgaben führen dazu, dass die Größe Personen-Monat als entscheidende Bezugsgröße im Planungsprozess ungeeignet ist.

Auf die weiteren Thesen des Buches gehe ich hier nicht ein. Der interessierte Leser kann diese aber zusammengefasst auf der englischen Wikipedia-Seite zum Buch nachlesen.

No Silver Bullet

In seinem Aufsatz "No Silver Bullet - Essence and Accident in Software Engineering" räumt Brooks mit der Hoffnung auf den großen Durchbruch in der Software-Entwicklung auf. Brooks teilt dazu die Schwierigkeiten bei der Softwareerstellung in zwei Klassen: In Schwierigkeiten, die der Natur der Software selbst innewohnen (essential difficulties) und denen, die mit der Art, das Problem zu lösen, zu tun haben (accidental difficulties). Die akzidentellen Schwierigkeiten umfassen beispielsweise Probleme, die mit der verwendeten Programmiersprache, der Methodik und dem Prozess zu tun haben.

Akzidentelle Schwierigkeiten konnten in der Vergangenheit durch Hochsprachen, geeigneten Werkzeugeeinsatz oder auch Modularisierung verringert werden, und auch zukünftig sind hier Verbesserungen zu erwarten. In der Java-Welt kann man als ein Beispiel für akzidentelle Schwierigkeiten die Entwicklung mit EJBs in den Versionen 1.x und 2.x anführen. Durch die EJB-Spezifikation 3.0 wurde die Entwicklung mit EJBs deutlich erleichtert und weitere Verbesserungen sind für die nächste Version geplant.

Das eigentliche Problem in der Software-Entwicklung stellen aber nicht die akzidentellen Schwierigkeiten dar, sondern die Probleme, die Software an sich innewohnen.

 Hier benennt Brooks vier Probleme:

• Komplexität
• Konformität
  
• Veränderlichkeit
• Unsichtbarkeit
  

Die Komplexität von Softwaresystemen wächst mit der Anzahl der Aufgaben und der zu verwaltenden Elemente stärker als linear an. Dieses Wachstum ergibt sich schon allein aus der Aufgabenstellung und der mit der steigenden Anzahl der Elemente zahlreicher werdenden Abhängigkeiten und Verflechtungen. 

Die Probleme der Softwareentwicklung verschärfen sich durch die geforderte Konformität. Konformität bedeutet, dass Software eine Vielfalt von Anforderungen abdecken muss, mit diesen konform gehen muss. Dies können Gesetzesvorgaben sein, aber auch Anforderungen der Nutzer an das System, die sich wiederum nicht mit den Anforderungen des Managements an das System decken müssen.

Da Software jederzeit aus den Sourcen neu generiert werden kann, unterliegt sie einer hohen Veränderlichkeit. Auftraggeber fordern bei Software Änderungen leichter ein als bspw. bei physikalisch vorliegenden Produkten wie Autos, Häusern oder Computern. Solche Produkte werden zumeist erst mit einer neuen Generation Änderungen enthalten. Bei Software hingegen werden Änderungen unmittelbar eingefordert und Nutzer kommen gerade durch den Einsatz des Produkts häufig erst auf Ideen für Verbesserungen. Schlussendlich geht der Lebenszyklus von Softwaresystemen über den Lebenszyklus der Ursprungshardware hinaus. Zumindest Systemsoftware (Betriebssysteme, Datenbanken etc.) muss darauf reagieren und angepast werden.

Die vierte Eigenschaft, die Software inhärent ist, ist ihre Unsichtbarkeit. Softwaresysteme lassen sich nur bedingt visualisieren und wenn, dann auf keinen Fall mit nur einem einzigen Diagramm oder 3D-Modell. Graphische Repräsentationen, physikalische oder virtuelle Modelle helfen sowohl Auftraggeber als auch Auftragnehmer, ein gemeinsames Verständnis vom Produkt zu bekommen. Dies ist beispielsweise in der Architektur oder dem Autobau möglich, in der Softwareentwicklung jedoch nur bedingt.

Diese vier Probleme lassen sich laut Brooks nicht - zumindest nicht entscheidend - verringern. Demnach kann man die Softwareentwicklung nur bedingt optimieren. Bahnbrechende Erfolge werden sich so voraussichtlich nicht ergeben.

Brooks zeichnet dennoch keineswegs ein düsteres Bild. Er bezeichnet sich selbst als Optimisten und glaubt fest an weitere, wenn auch langsame, schrittweise Verbesserungen. So setzt er seine Hoffnung auf eine verstärkte Modularisierung und Kapselung und auf visuelle Repräsentationen (der Plural ist hier entscheidend) des zu erstellenden Systems. Darüber hinaus bietet sich häufig auch, so Brooks, Kaufsoftware an. Gekaufte Software ist heutzutage freilich in aller Regel durch Freie Software zu ersetzen. Die größte Hoffnung liegt Brooks zufolge allerdings in der Auswahl geeigneter Entwickler und Designer - eine Hoffnung, die er mit anderen Experten teilt.

Es ist erstaunlich, wie modern sich Brooks nach mehr als zwanzig Jahren noch liest. So kann man sein Plädoyer für stärkere Kundeneinbindung, iterative Zyklen und für Rapid Prototyping als Aufruf zu einer agilen Methodik lesen. Auch warnt er davor, eine Sprache zu überfrachten (eine Diskussion, die in der Java-Welt derzeit im Gange ist), weist aber auch darauf hin, dass man der Wahl der Sprache nicht zu viel Bedeutung zumessen sollte.

Kritiker von Brooks

Die im Buch "The Mythical Man-Month" vertretenen Thesen sind bis heute weitgehend unwidersprochen. Der Aufsatz "No Silver Bullet" hingegen wurde mehrfach kritisiert. Zwei interessante kritische Beiträge sind David Havels Artikel "Biting the Silver Bullet. Toward a Brighter Future for System Development" (erschienen in der IEEE-Zeitschrift "Computer" vom Januar 1992 und auf deren Website gegen Bezahlung erhältlich) und Brad J. Cox Beitrag "There Is a Silver Bullet" im Dr. Jobbs Journal vom Dezember 2004. Beide Kritiker bringen viele wichtige Ergänzungen, können aber Brooks These nicht überzeugend widerlegen. Brooks selber geht in einem Kapitel der zweiten Auflage seines Buches "The Mythical Man-Month" auf beide (und weitere) Kritiker ein. Ein weiterer Grund, sich das Buch vorzunehmen ;-)

Konsequenzen? Leider Fehlanzeige!

Obwohl die erste Auflage des Buches bereits 1975 erschienen ist, 1995 eine Jubiläumsausgabe folgte und 2003 auch eine deutsche Ausgabe herausgekommen ist (2004 sogar als Hörbuch), hat man in der täglichen Arbeit das Gefühl, dass es diese Texte nie gegeben hätte.
Was sehen wir im Projektalltag beispielsweise immer wieder? Genau den von Brooks kritisierten Versuch, das Projekt durch zusätzliche Leute zu retten. Und dies häufig auch noch zu einem sehr späten Zeitraum im Projekt, wenn sich das höchstwahrscheinliche Reißen der Deadline nicht mehr verheimlichen lässt. Management und Projektleitung sind sich erschreckend einig darin, die Warnungen Brooks' zu ignorieren, und verwenden Personenjahre immer noch als zentrale Planungsgröße.
Derweil wird regelmäßig eine neue Technologie oder Methode als der Stein der Weisen gefeiert. Mal ist es Strukturierte Programmierung, später Objektorientierung, ein anderes mal Komponentenorientierung oder in jüngerer Zeit SOA, inzwischen ergänzt um den Enterprise Service Bus. Hauptnutznießer sind nicht die Abnehmer und Nutzer der Software, auch nicht die Firmen, die hoffen, mithilfe dieser Technologien schneller bessere Software entwickeln zu können, als vielmehr die Hersteller der zum aktuellen Hype passenden Tools und die Consultants, die die neue Technologien predigen und in die Entwicklungsmannschaften tragen sollen.
Zugegeben, viele dieser Methoden und Techniken haben gegenüber der vorherigen Art, Software zu entwickeln, tatsächlich Verbesserungen gebracht. Allerdings waren dies stets nur graduelle Verbesserungen und keineswegs die vielfach gepriesenen Durchbrüche. Und wenn Brooks Recht hat, dürfte das Mildern der akzidentellen Probleme für den Gesamtaufwand immer weniger Bedeutung haben. Schließlich ist der Kern des Problems, sind die essentiellen Probleme bis heute nicht gelöst. Und es ist offen, ob eine Lösung überhaupt möglich ist. Die immer wieder marktschreierisch angepriesenen Tools, Prozesse und Hypes sind es jedenfalls nicht. Turski fasst es passend zusammen (zitiert nach Brooks):

In dem Sinne: Happy Coding!

Gepostet am 14.02.2008 um 21:28  |  Kommentare[1]