Neujahrsgedanken (II)

von Sascha Frick (Oktober 04)

Nun liegen sie also vor uns: 12 unverbrauchte Monate voller neuer Chancen und Herausforderungen. Die Sterne, sagen die Astrologen, stehen recht günstig für Glück und Erfolg, und glaubt man den Wirtschaftsauguren, so soll auch der mehrmals verschobene Aufschwung nun endlich kommen. Wie auch immer 2004 dann wirklich verlaufen wird, eines ist jetzt schon klar: Auch dieses Jahr wird uns wieder viele Herausforderungen bringen.

In der neusten Ausgabe von Technology Review nennt Bruce Sterling 10 Technologien, die aus seiner Sicht verschwinden sollten (10 Technologien, die verschwinden sollten). Nach der Lektüre dieses sehr lesenswerten Artikels, habe ich mir überlegt, welche 10 Dinge in der Softwareentwicklung verschwinden sollten. Hier also meine persönliche Liste:

Der OK-Knopf hat in einem Fehlermeldungsdialog nun wirklich nichts zu suchen. Hey, schliesslich ist gerade ein Fehler aufgetreten, also ist gar nichts OK. Da ist es doch eine Zumutung, so tun zu müssen, als sei es in Ordnung, dass als Folge des aufgetretenen Fehlers mit grosser Wahrscheinlichkeit wieder einmal die noch nicht gespeicherte Arbeit der vergangenen Minuten zunichte gemacht wurde. Was konkret verloren gegangen ist, bleibt dabei dem Anwender überlassen herauszufinden. Das finden wohl die wenigsten Anwender wirklich in Ordnung. Darum: Weg mit dem OK-Knopf in Fehlerdialogen – oder noch besser: Weg mit den Fehlern!

Wir brauchen wirklich nicht alle 6 Monate einen neuen Trend, eine neue wegweisende Technologie (die man früher übrigens unspektakulär schlicht als Technik bezeichnete) oder gar ein bahnbrechend neues Paradigma. Es ist zwar nachvollziehbar, dass Marketingleute etwas für ihr Geld tun müssen, aber es nervt einfach, ständig mit diesen Ankündigungen, aus denen dann doch nichts wird, bombardiert zu werden. Darum ein kurzes Zitat von Erich Kästner für die, die es angeht: Wollt ihr schon nicht weise sein, könntet ihr dann bitte leise sein!

Es mag uns in einer auf zunehmende Flexibilisierung ausgerichteten Welt anachronistisch erscheinen und uns sogar missfallen – aber: Der beste Garant für den Erfolg sind motivierte Menschen, die zusammen für die Erreichung eines Ziels arbeiten. Vom Einzelnen verlangt dies Kommunikations- und Konfliktfähigkeit, Fachkompetenz und Mut. Für die fruchtbare Zusammenarbeit von Menschen sind aber auch stabile soziale Makro- und Mikro-Strukturen notwendig. Ersteres ist ein gesellschaftspolitisches Thema, während letzteres die Unternehmen selbst angeht: eine auf die kurzfristige Bilanzoptimierung ausgerichtete Hire&Fire-Politik und ständige Restrukturierungen, die erfolgreiche Teams regelmässig auseinander reissen, zeugen weder von besonderem Verantwortungsbewusstsein, noch sind sie aus ökonomischer Sicht klug geschweige denn nachhaltig. Gerade kreative und intellektuell anspruchsvolle Arbeiten wie das Entwickeln von Software sind dabei besonders anfällig für dysfunktionale Strukturen. Nicht zuletzt deswegen, scheint hier ein Sinneswandel im Top-Management vieler Unternehmen dringend geboten.

Das Schreiben von Software ist eine echte intellektuelle Herausforderung; jede und jeder, der es einmal versucht hat, weiss das – hoffentlich. Als Softwareentwickler müssen wir Tag für Tag knifflige Probleme lösen. Das erfordert Hirnschmalz und ist anstrengend – wem das nicht gefällt, sollte sich schleunigst umschulen lassen. Das verlässlichste Werkzeug bei dieser Arbeit ist unser eigener Intellekt. Denn auch im Jahre 2004 gilt: Kein Werkzeug und keine heute verfügbare Technologie kann uns das Denken abnehmen. Es geht dabei nicht darum, den Einsatz von Tools zu verdammen, vielmehr ist dies ein Plädoyer für einen besonnenen Umgang mit den heute verfügbaren Werkzeugen. Ist es denn wirklich erstrebenswert, Stunden mit dem Debugger zu verbringen, anstatt sich mit Hilfe eines Unit-Tests Klarheit zu verschaffen? Ist es wirklich nötig, sich mittels eines Profilers auf die Suche nach Speicherlecks zu machen, die ein sauberes Konzept zur Objektlebenszeit bereits im Vorfeld verhindert hätte? Viele Entwickler scheinen eher bereit, ein neues Tool einzusetzen als mit lieb gewonnenen Gewohnheiten zu brechen.

... für Dinge, die wir nicht verstehen. Tausende Zeilen von Quellcode mit Hilfe eines Code-Zauberers erzeugen zu lassen, die man nicht versteht, ist nicht besonders schlau. Denn anders als bei Bibliothekscode, der sich als Blackbox hinter einer sauberen Schnittstelle verbirgt, ist generierter Code Applikations-Code. Und für den sind wir selber verantwortlich. Wer den generierten Code nicht versteht, hat damit ziemlich schlechte Karten, wenn es um das Testen oder gar das Suchen und Beseitigen von Fehlern geht. Wenn Sie glauben, dass Sie mangelnde Qualifikation durch den Einsatz eines Code-Zauberers wettmachen können, dann lassen Sie sich auf ein ziemlich gefährliches Spiel mit geringen Gewinnchancen ein.

Der juristische Ausdruck As-is bedeutet zu Deutsch: ohne Mängelgewähr. Für Komponenten-Hersteller ist diese Formulierung in den Lizenzbestimmungen der gross und breit angelegte Notausgang, den sie mit schöner Regelmässigkeit benutzen, um sich aus der Verantwortung zu stehlen, wenn eine Komponente wieder einmal nicht das tut, was sie sollte. Zurück bleibt der Entwickler, der dann versuchen muss, einen Weg zu finden, um die Sache doch noch zum funktionieren zu bringen. Es ist beschämend und ernüchternd feststellen zu müssen, dass immer noch eine Vielzahl von Komponentensammlungen für teures Geld verkauft werden, die schwierig zu verwenden, schlecht dokumentiert und obendrein noch fehlerhaft sind. Da muss sich niemand wundern, wenn unsere Branche in Punkto Qualität einen schlechten Ruf hat.

Softwarepatente sind schädlich. Sie dienen lediglich den Interessen multinationaler Grosskonzerne und den Marken- und Patent-Anwälten. Für alle anderen sind Softwarepatente Gift. Zusammen mit den Bestrebungen der Inhaltsanbieter, die vollständige Kontrolle über sämtliche Inhalte zu erlangen (Stichwort: DRM, TCP und Verschärfung des Urheberrechts) sind Softwarepatente eine ernsthafte Gefahr für die freie Verbreitung von Wissen in der Welt. Denn der Austausch von Wissen ist einer der Grundpfeiler in freien Gesellschaften, und der digitale Graben ist auch so schon gross genug. Für unser Unternehmen würden Softwarepatente letztlich wohl das Aus der Entwicklung eigener Software bedeuten. Den zu treibenden Aufwand, um überhaupt festzustellen, ob wir möglicherweise eines der zahlreichen (Trivial-)Patente verletzen, könnten wir uns schlicht nicht leisten. Übrigens: Im EU-Parlament wurde der Versuch, Softwarepatente auch in Europa durchzusetzen fürs erste zwar abgeschmettert. Doch die Gefahr ist noch nicht gebannt: Die endgültige Entscheidung wurde lediglich aufgeschoben.

Viele gute Ideen in der Informatik sterben früher oder später den Komplexitätstod. Was einmal einfach und überschaubar begonnen hat, wächst sich über die Zeit mehr und mehr zu einer wahren Schlangengrube an Komplexität aus. Hier nur zwei Beispiele:

• Die Java Plattform – Jede neue Version bringt neue Leistungsmerkmale und zusätzliche Komplexität. Die J2EE ist heute bereits so komplex, dass man sich fragen muss, wer damit wirklich noch umzugehen vermag. Und die mit Java 1.5 (Codename Tiger) angekündigten Erweiterungen – obwohl teilweise sinnvoll – führen zu einer schleichenden Überfrachtung von Java.
• Die UML – Der Versuch alles, aber auch wirklich alles mit Hilfe der UML ausdrücken zu wollen, führt mehr und mehr zu ungewollter Komplexität und schmälert den Nutzen der Unified Modeling Language beträchtlich. Gewisse Diagrammelemente der UML 2.0 sind in ihrer Darstellung bereits einfacher Sachverhalte so komplex, dass ein durchschnittlicher Betrachter verzweifelt. Die Idee, einen durch ein paar Zeilen Programmcode beschreibbaren Sacheverhalt mit Hilfe von drei (!) verschiedenen Diagrammen der UML 2.0 darzustellen, die für das Verständnis dann auch noch zueinander in Beziehung gesetzt werden müssen, ist absurd.

Die Model Driven Architecture (MDA) ist eine dieser Marketinglügen, die der gestandene Informatiker einfach nicht mehr glauben mag. Modelle sind etwas gutes, daran besteht kein Zweifel, wir alle benutzen sie tagtäglich. Nur: die Modell-Definition der MDA und die zugrunde liegende Prämisse, man müsse nur das manuelle Schreiben des Quellcodes abschaffen, um die Softwarekrise endlich zu bewältigen, ist wenig überzeugend. Diese Argumentation verfängt höchstens im Management und zeugt von einem grundlegenden Missverständnis bezüglich dessen, was Softwareentwicklung bedeutet. Und wenn dann in einem Vortrag zu den Vorzügen der MDA Sätze zu hören sind wie „Die MDA erlaubt höhere Produktivität durch automatisch erzeugte Komplexität“ dann sind zumindest Zweifel erlaubt, ob das Ganze wirklich so eine kluge Idee ist.

Es scheint ja auf den ersten Blick sehr praktisch, das Freigeben von nicht mehr benötigten Objekten dem Computer zu überlassen. Leider bekämpft Garbage Collection dabei lediglich Symptome und nicht die Ursachen, da sie am eigentlichen Thema vorbeigeht:

Objektlebenszeit (Object Lifetime). Das Schlimme dabei: Dem Entwickler wird vorgegaukelt, dass er sich keine Gedanken mehr um die Lebenszeit seiner Objekte machen muss. Damit wird Garbage Collection zur Lizenz für Idioten, eine Riesensauerei in ihren Programmen zu veranstalten, um die sich dann der Garbage Collector – der Name ist Programm – kümmern muss.

Aber kann Garbage Collection das wirklich leisten? Leider nein - Garbage Collection löst keines seiner Versprechen wirklich ein: Weder wird das Verwalten der entstehenden Objektnetze einfacher – eher das Gegenteil ist der Fall - noch werden Speicherlecks zuverlässig verhindert (Stichwort Loiterers).

Beim Entwurf einer Software sind Überlegungen zur Lebenszeit der benötigten Objekte - wie gesagt - zentral und beeinflussen die gewählte Implementierung wesentlich:

Für jedes Objekt, das als Argument einer Methode übergeben wird, muss klar sein, ob mit der Übergabe auch die Besitzrechte für dieses Objekt übergeben werden, oder ob das Objekt lediglich bis zu einem bestimmten(!) Zeitpunkt durch das aufgerufene Objekt verwendet wird. Gleiches gilt sinngemäss für Objekte als Rückgabewerte einer Methode.

Diese Überlegungen sind für ein robustes System unabdingbar– und zwar mit oder ohne Garbage Collection. Damit bleibt von den vermeintlichen Vorzügen durch den Einsatz eines Garbage Collectors nicht mehr viel übrig. Denn die eigentliche Herausforderung für einen Entwickler besteht nicht darin, den Speicher für ein nicht mehr benötigtes Objekt freizugeben, sondern vielmehr darin, sich Gedanken darüber zu machen, wo und wie lange ein Objekt sicher verwendet werden darf. Und eben diese Arbeit nimmt einem auch der Garbage Collector nicht ab – die Objektlebenszeit ist und bleibt ein konzeptionelles Thema, um das sich der Software-Entwickler zu kümmern hat.