Evolutionäres Programmieren: Die Rückkehr der Künstlichen Intelligenz in die Software-Entwicklung

Hartmut Schlosser

Wer Software-Naturalismus betreibt, braucht heutzutage eine dicke Haut:

Eine Bestandsaufnahme der Leistungen der gesamten Entwickler-Zunft fördert das ernüchternde Ergebnis zu Tage, dass gut funktionierende Programme eher die Ausnahme denn die Regel sind. Gescheiterte Projekte gibt es zuhauf, Statistiken zufolge erreichen ca. 20 Prozent der Projekte nicht die Produktionsreife. Über 50 Prozent der Projekte sind problematisch in dem Sinn, dass sie verspätet auf den Markt kommen, dass wichtige Funktionen nicht implementiert wurden, dass gewichtige Bugs enthalten sind oder dass die Performance nicht stimmt.

Der Chaos Summary Report geht von einem dürftigen Drittel der Projekte aus, die man als „erfolgreich“ abgeschlossen betrachten kann, die also alle Anforderungen an Funktion, Budget und Zeitplan erfüllten. Im Umkehrschluss heißt das: Zwei Drittel aller Projekte laufen aus dem Ruder – Ihres auch?

Maßnahmen gegen das große Scheitern

Zufrieden kann die IT mit dieser Bestandsaufnahme wahrlich nicht sein. Und in der Tat werden seit Jahren und Jahrzehnten neue Maßnahmen zur Qualitätsverbesserung ersonnen:

  • Integrierte Entwicklungsumgebungen
  • Typsichere Sprachen
  • Libraries und Frameworks, die funktionierende Komponenten bereitstellen
  • Automatisierte Testumgebungen
  • Agile Software-Entwicklung mit schnellen Feedback-Zyklen
  • Code-Generierung
  • Modularisierung
  • Domänen-spezifische Sprachen
  • DevOps
  • etc.

Doch die Negativ-Statistik der scheiternden Projekte bleibt – und angesichts des Vorhandenseins dieses Arsenals an Tools und methodischem Handwerkzeug wird dieser Sachverhalt noch brisanter.

Schuld ist der gute alte Sachzwang?

Bei einer Analyse für die Gründe des allgemeinen Scheiterns werden schnell Sachzwänge innerhalb von Unternehmen genannt: unrealistische Vorstellungen des Managements, zu eng gestrickte Zeitpläne, zu kleine Budgets, etc. Ein realistisches Requirements Engineering identifizieren Chris Rupp und Carsten Pflug in ihrem Artikel „Warum Projekte tatsächlich scheitern“ deshalb auch als wesentlichen Faktor für erfolgreiches Projektmanagement.

Auch eine Bewegung wie die des Software Craftmanship fordert, sich nicht den Sachzwängen des Unternehmensalltags zu unterwerfen und das Handwerk, manche sagen die Kunst, des Programmierens wieder in den Mittelpunkt zu stellen.

Hier Bob Martins Abriss der Forderungen aus dem Manifesto for Software Craftmanship:


Folgende Tätigkeiten sollen unterlassen werden:

  • Wir liefern keinen schlechten Code mehr ab, nur um Releasepläne einzuhalten.
  • Wir akzeptieren nicht die alte dumme Lüge, die Dinge später einmal ins Reine zu bringen.
  • Wir glauben nicht an die Behauptung, dass schnell auch „unsauber“ bedeutet.
  • Wir erlauben es keinem, uns dazu zu zwingen, unprofessionell zu handeln.
  • Von jetzt an soll hingegen folgende Praxis umgesetzt werden:

    • Wir werden unsere Zeitpläne einhalten – mit dem Bewusstsein, dass „schnell sein“ nur auch bedeutet, gut zu sein.
    • Wir werden unsere Kunden zufrieden stellen, indem wir den besten Code abliefern, den wir schreiben können.
    • Wir werden unsere Auftraggeber ehren, indem wir das beste Design abliefern, das wir entwickeln können.
    • Wir werden unser Team ehren, indem wir alles testen, was getestet werden kann.
    • Wir werden bescheiden genug sein, zuerst unsere Tests zu schreiben.
    • Wir werden ständig trainieren und uns weiterbilden, um besser in unserem Beruf zu werden.

    Doch schiebt man da den schwarzen Peter nicht einfach den Umständen oder den „unfähigen Anderen“ zu? Projekte scheitern weiterhin – trotz Agile, DevOps, Software-Craftmanship. Vielleicht kommt man da auch auf den Gedanken, dass die einzige Wahrheit darin besteht, dass für ein gutes Projekt auch gute Arbeiter Hand anlegen müssen – gute Entwickler, gute Architekten, gute Projektmanager?

    Evolutionäre Programme

    Einen Denkanstoss gibt Agustín Ramos nun in seinem Blogeintrag „I don’t want to be a software craftsman… but I have to.“ Gute Entwickler seien nicht nur rar. Auch gute Entwickler seien beim heutigen Stand der IT-Industruie nur wieder in der Lage, relativ zerbrechliche Gebilde zu schaffen. Statt weiter dem Ideal des Software-Künstlers nachzueifern – ein Ideal, das realistisch betrachtet nur eine Minderheit erreichen wird – denkt Ramos über Wege nach, wie Programme selbst dafür sorgen können, dass sie besser werden.

    I’d like to create really robust software in an inexpensive way, and my guess is that by handcrafting it we can not get too far. We have to take a look at growing software by automated means. Agustín Ramos

    Ramos bemüht den etwas gewagten Vergleich eines Programmes mit einem biologischen Organismus. Forschungen zeigen, dass Programme Eigenschaften aufweisen, die nicht von den Programmierern intendiert waren. Dazu gehört auch eine unerwartete Robustheit an Stellen, an denen man es nicht vermutet hätte. Kleine zufällige Änderungen – Mutationen – am Programmcode, wie das Verändern einer Zahl, eines Zeichens, eines Operators, haben in 30 Prozent der Fälle keinen Einfluss auf das korrekte Verhalten von Programmen. Eine der Forscherinnen auf diesem Gebiet Stephanie Forrest meint, dass Programme ähnlichen Konditionen unterliegen wie biologische Systeme – und dazu gehört auch eine gewisse Mutationsrobustheit.

    Angesichts dieses biologischen Vergleichs schlägt Ramos vor, die Automatisierung der Software-Entwicklung weiter voran zu treiben und an Ergebnisse aus universitären Forschungen anzuknüpfen. Er verweist auf Nichael Cramer und John Koza, die die Idee von Programmen verfolgten, die selbst wieder Programme schreiben. Unter dem Namen Genetic Programming haben die beiden generische Algorithmen ersonnen, die in der Lage waren, Programme zu erzeugen, die gemäß acht Kriterien mit von Menschen geschriebenen Programmen konkurrieren konnten.

    Könnte diese „Genetische Programmierung“ ein Mittel gegen das Scheitern vieler Projekte darstellen?

    Die Rückkehr der Künstlichen Intelligenz

    Was von Ramos hier beschrieben wird, klingt ja so fantastisch nicht – hat in der Industrie heutzutage jedoch einen äußert schlechten Ruf. Grund ist eine Disziplin, die einmal mit einem ähnlichen Versprechen an den Start gegangen ist: MDA – Model Driven Architecture. Programme anhand eines grafischen Architekturmodells auf Knopfdruck zu generieren, hat nie wirklich reibungslos funktioniert. Software-Modellierer geben sich heutzutage bescheidener und sprechen von MDSD – Modell-getriebener Software-Entwicklung.

    Doch eigentlich geht Ramos´ noch weiter, und zwar in Richtung Künstliche Intelligenz. Das Thema KI hat sich nach dem Hype in den 60er und 70er Jahren immer weiter von der Mainstream-IT entfernt – warum eigentlich? An den Universitäten wird dieses Thema in Grundkursen abgehandelt. Im Berufsleben hat man mit KI allenfalls bei der Spieleprogrammierung zu tun. Ramos geht es darum, die Erkenntnisse aus der KI-Forschung für die industrielle Software-Entwicklung fruchtbar zu machen und trotz mancher gescheiterter Versuche am Gedanken der „sich selbst weiterentwickelnden Software“ festzuhalten.

    We as an industry should take responsibility of creating our own tools. We should understand, pursue, and bring to mainstream ideas and techniques about evolvable software. It’s our job. Agustín Ramos

    Naiv erwartet Ramos nicht, bald große Systeme eigenständig heranwachsen zu lassen. Das folgende Szenario hält er indes für plausibel:

    A software designer that specifies the modules for his application, then selects off-the-shelf components to fulfill certain tasks or features, and then designs growing environments to synthesize each missing module, given a proper test suite as „fitness function“.Agustín Ramos

    Der Entwickler der Zukunft: Zwischen Handwerker und Gärtner

    Sollte ein solches Szenario Realität werden, verschiebt sich der Fokus eines Entwicklers vom Handwerker (Craftsman) zum Gärtner (Farmer):

    I other words, I’d rather be a software farmer, if you like, and fall back to craftsmanship only when needed.

    In the mean time, the only option to do professional software development is to embrace craftsmanship. That is, the idea of handcrafting with extreme care and responsibility every single bit of every piece of software. Agustín Ramos

    Was meinen Sie? Sollten wir uns als Entwickler zukünftig eher in die Rolle eines „Software Farmers“ einfinden und nur dann auf das Handwerk Software-Entwicklung zurückgreifen, wenn nötig? Oder wo sollte man Ihrer Meinung nach ansetzen, um das große Dilemma der scheiternden Software-Projekte zu überwinden?

    Geschrieben von
    Hartmut Schlosser
    Kommentare

    Schreibe einen Kommentar

    Deine E-Mail-Adresse wird nicht veröffentlicht.