Software zu entwickeln ist schwierig. Wenn Sie sich mit Softwareentwicklung näher beschäftigen, wissen das. Darum gehört Weiterbildung für uns Softwareentwickler eigentlich zum Alltag. Letzte Woche war ich auf einer dieser Entwicklerkonferenzen. Sie wissen schon: Essen vom Buffet, jede Menge Vorträge zu unterschiedlichen Themen, Technical Keynotes, Produktankündigen, Heilsverkündungen und jede Menge „Softwareentwickler“.
Eigentlich mag ich solche Konferenzen nicht, doch ab und zu kann ich mich dennoch dazu überreden, an einer teilzunehmen. Nach der Konferenz bin ich meistens ziemlich mürbe und entnervt, und ich schwöre mir: nie wieder… bis zum nächsten Mal. Was ist denn so schlimm an solchen Konferenzen, mögen Sie fragen. Kurz gesagt: Das Schlimmste ist jeweils die Erkenntnis, wie schlimm es um unsere Branche steht. Noch immer dominieren Werkzeuge über die Vernunft, noch immer werden die Heilsverkünder eingeladen, um über das neuste Dreibuchstaben-Akronym zu berichten, von dem ein Jahr später keine Rede mehr sein wird. Noch immer dominieren technische Diskussionen auf dem Niveau von: Welchen Datenbanktreiber soll ich verwenden, welches Tool erledigt für mich Aufgabe Xyz, welche Bibliothek bietet die schönsten Knöpfe, Listboxen usw.? Noch immer scheint die Meinung allgegenwärtig, die heutigen Probleme der Softwareentwicklung liessen sich alleine durch Tools und Methoden lösen. Vergessen scheint der eigene Kopf, wenn es darum geht, komplexe Probleme wirklich zu lösen anstatt sie einfach weg zu klicken. Schleichend breitet sich die
Klickeritis aus wie eine Krankheit und fast möchte man meinen, die in die Jahre gekommenen LOC- (Lines of Code) Metriken seien durch NOC- (Number of Clicks) Metriken ersetzt worden.
Sie können sich vielleicht vorstellen, wie beliebt ich mich an solchen Konferenzen jeweils mache, wenn ich mich an dieser übertriebenen Toolverliebtheit störe. Für mich bedeutet das Schreiben von Software, kritisch und sorgfältig über Probleme und ihre Lösung nachzudenken, mutige Entscheidungen zu treffen, so dass schliesslich wirkliche Software entsteht. Werkzeuge sind eine wertvolle Hilfe, nehmen mir aber nicht das Denken ab. Dabei spielt Abstraktion und der sorgfältige Umgang mit Komplexität eine wichtige Rolle. Wir abstrahieren, um besser mit Komplexität umgehen zu können, und wir müssen bestrebt sein, die Dinge nicht unnötig kompliziert zu machen. Schliesslich ist das Schreiben einer zeitgemässen Anwendung schon so schwierig genug: Mehrschichtig, web-basiert, Drag&Drop Unterstützung, OLE- und multidatenbank-fähig sind nur einige der geforderten Leistungsmerkmale. Und natürlich am besten bereits nächste Woche. Na klar doch, hier bitte schön, gern geschehen und nächstes Projekt, bitte. Die Hersteller haben selbstverständlich eine Lösung für dieses Problem: Codezauberer in Form von Experten, die auf Knopfdruck hunderte oder gar tausende Zeilen von Programmcode erzeugen. Einfach ein paar Fragen beantworten, ein Klick hier, ein Klick da, und schon spuckt ein Codegenerator einen Webservice, eine mehrschichtige Datenbankanwendung etc. aus. Der Programmierer muss dann „nur“ noch ein paar Zeilen Businesslogik-Code ergänzen, und schon ist die Sache geritzt!
Natürlich ist es hilfreich, für komplexe wieder kehrende Probleme Unterstützung zu haben. Doch die Verwendung eines Experten macht uns selbst noch lange nicht selbst zu einem Experten. Die Verwendung eines Codegenerators für Code, den wir nicht verstehen, ist zumindest gefährlich. Solange wir den generierten Code nicht ändern müssen, mögen wir uns in der trügerischen Sicherheit wiegen, alles im Griff zu haben. Aber spätestens, wenn der automatisch erzeugte Code nicht das tut, was er sollte oder sich die Anforderungen ändern, stehen wir schnell alleine da. Damit wir uns richtig verstehen: Ich bin nicht gegen Codegeneratoren an sich, wir setzen sie in unserer Firma häufig ein, um wiederkehrende Probleme zu lösen. Aber die Voraussetzung ist, dass wir den Code, den sie generieren
verstehen. Wenn wir dagegen auf die Magie eines Codezauberers vertrauen und den Code nicht verstehen, den er generiert, dann haben wir schlicht und ergreifend die Kontrolle über unsere Software verloren; Testen, Fehlerbehebung und Debugging werden dann zu einer Lotterie.
Nun mögen Sie das für eine ziemlich engstirnige und extreme Position halten. Schliesslich verwenden wir alle ständig Dinge, die wir nicht vollständig verstehen und auch nicht verstehen müssen. Das beste Beispiel dafür sind die internen Details eines Mikroprozessors oder die Implementierungsdetails einer Code-Bibliothek, die wir verwenden. Und das ist sicher richtig. Aber diese Blackbox-Betrachtung funktioniert nicht für den vom Codezauberer erzeugten Code. Denn dieser ist eben nicht einfach eine Blackbox, die über eine hübsche Schnittstelle verfügt, über die wir den generierten Code ansprechen können. Dieser Code ist integrierter Bestandteil unserer Anwendung, die
wir warten und verstehen müssen. Der Codegenerator hat längst Feierabend, während wir immer noch versuchen, die generierten Programmzeilen und unseren eigenen Code, der mehr und mehr mit dem generierten Code verschmilzt, in den Griff zu bekommen; was einst als generierter Code zur Welt gekommen ist, ist nun zu unserem Code geworden. Und für den sind wir
alleine verantwortlich.
Es lohnt sich, kritisch darüber nachzudenken, ob und wann wir Codegeneratoren einsetzen wollen. Oft stehen uns bessere Möglichkeiten zur Verfügung, um mit wiederkehrenden Grundstrukturen und Variationen im Detail umzugehen. So können wir zum Beispiel Techniken aus der
Metaprogrammierung anwenden oder bestimmte Aspekte in wieder verwendbare Komponenten auslagern. Dadurch lässt sich die Zahl der Fälle, in denen irgendwelche Zauberer Tricks vollführen müssen, bereits merklich reduzieren.
Codegeneratoren haben ihren Wert. Doch sie lösen nicht das eigentliche Problem. Nicht das Schreiben des Quellcodes an sich kostet Zeit und Geld, sondern das Nachdenken darüber, wie der Code so geschrieben werden kann, dass er das anstehende Problem korrekt und verlässlich löst und sich bei Bedarf mit angemessenem Aufwand an neue Anforderungen anpassen lässt. Wer sein Heil in generiertem Code sucht und auch noch glaubt, diesen Code nicht verstehen zu müssen, der betreibt Programmierung durch Zufall in übelster Art und Weise. Daher weigere ich mich, für Code verantwortlich zu sein, den ich nicht verstehe. Denn wenn ich von Beginn weg nicht weiss, warum mein Code funktioniert, wie soll ich dann wissen, warum er plötzlich nicht mehr funktioniert?
Simplicity is the most difficult thing to secure in this world; it is the last limit of experience and the last effort of genius.