Für altgediente Softwareanwendungen mit langer Lebenszeit gibt es keine Kennzeichnung mit „H“ – warum eigentlich nicht? Ihr Alter macht sich zumeist durch antike, sprich angestaubte Bedienkonzepte und Technologien aus der Kreidezeit bemerkbar. Während Besitzer von Oldtimern unkomfortable, langsame, dafür aber vermeintlich romantische Fahrten genießen, hält sich derartige Euphorie bei Nutzern von Legacy-Code spürbar in Grenzen. Renovierungs- und Modernisierungsaktivitäten ereignen sich bei Software mitunter in längeren Zeitspannen als bei Gebäuden. Und nicht zuletzt wachsen die Softwaresysteme mit der Zeit über sich hinaus – ich sage nur Patches, Bug-Fixes und Refactoring. Das torpediert sie bei BMI-Vergleichen locker in die Top-3. Derlei Schwergewichte benötigen kräftiges Pflegepersonal und manchmal einen Arzt, der über Tools wie Tomographen, Analysegeräte, Operationsbesteck und gelegentlich auch über Knochensägen verfügt.
Jini und Java-Applets brauchen ein H-Kennzeichen
Das Problem tritt in den besten Familien zutage, also auch in der Familie der Java-Anwendungen. Wenn wir die Menge der seit der Java-Einführung kommenden und gehenden Technologien und Paradigmenwechsel betrachten, überrascht das kaum. Oder kennen Sie jemanden, der heute noch Jini oder Java-Applets nutzt, wobei sich Letzteres ohnehin nur mit steinzeitlichen Browsern realisieren ließe? Aufgrund der sich immer mehr beschleunigenden Technologieentwicklung fallen selbst Systeme in die Schublade „Legacy“, die nur wenige Jahre auf dem Buckel haben. Es ist fast wie beim Autokauf. Kaum steht das brandneue Fahrzeug vor der Tür, zählt es schon als Gebrauchtwagen.
Wenn Sie glauben, ich übertreibe ein wenig, haben Sie vollkommen recht. Real existierende Legacy-Systeme beinhalten auch Perlen, in die viel Erfahrung und Kompetenz geflossen sind. Ein wenig entstauben, Rost entfernen, hier und da Teile austauschen, das reicht gelegentlich aus, um die Perlen wieder auf Hochglanz zu polieren. Zumindest in der Theorie.
In der Praxis verhält sich die Angelegenheit oft anders. Im Gegensatz zu Handwerkern bekommen es Softwareentwickler mit komplexen, fest integrierten Komponenten zu tun, die sich nicht immer (einfach) aus ihrem Kontext beziehungsweise Umgebung lösen lassen, ganz nach dem Motto, „Wenn Sie die Banana wollen, bekommen Sie den Gorilla mit dazu“. An Nachhaltigkeit war schließlich bei der Entwicklung des Gesamtkunstwerks nicht zu denken, denn Projektlaufzeiten sind erstens immer endlich und zweitens stets kürzer als gedacht.
Erschwerend kommt hinzu, wenn die ursprünglichen Architekten inzwischen ihre Rente genießen und die Dokumentation wahlweise nicht geschrieben, mit Fantasie in psychodelischer Trance verfasst oder an einem unbekannten Ort abgelegt haben. Der stets lesenswerte „Hitchhiker‘s Guide to the Galaxy“ lässt grüßen. Für die aktuellen Softwarearchitekten gilt für Legacy-Aufräumarbeiten dann das Star Trek-Mantra: Wir stoßen in unendliche Weiten vor, die nie ein Mensch zuvor gesehen hat. Doch was tun in solchen Fällen?
LLMs können alles, nur nicht verstehen
Fanfaren ertönen, das Publikum klatscht begeistert Beifall! KI tritt auf die Bühne und rettet uns auch bei diesem Problem. Wobei viele Zuschauer sich nicht dessen bewusst sind, dass sie an einem Improvisationstheater mitwirken. Ein LLM macht gar nichts, außer man sagt ihm präzise und eindeutig, was es tun soll. Und wehe, es erhält nicht alle relevanten Fakten. Da erfindet es schon man welche hinzu. Als Vertreter der KI- (oder moderner: Generative KI-)Glücksritter kann ich nur warnen. Wer KI einsetzt, sollte a) mit den verwendeten KI-Algorithmen, b) mit den vorhandenen und auch mit den generierten Softwareartefakten vertraut sein, und eine gehörige Portion Misstrauen mitbringen. Wie Lenin schon sagte, „Vertrauen ist gut, Kontrolle ist besser!“
Bei größeren Codebasen mit mehreren Millionen Zeilen Code erweisen sich LLMs als äußerst hilfreich, sofern Sie auch in der Ära der, laut Hersteller, bald superintelligenten KIs auf mittelalterlich anmutende Werkzeuge wie SonarQube, Structure101, Understand zurückgreifen. Und natürlich auf die menschliche Vernunft und Erfahrung von Architekten und Entwicklern, denn: LLMs können alles, nur nicht verstehen. Soeben ringt ein Gedanke in meinem Kopf um Aufmerksamkeit: Entwickler, vergib‘ ihnen, denn sie wissen nicht was sie tun! Allerdings können traditionelle Tools präzise die Syntax analysieren, LLMs zwischen den Zeilen und über den Tellerrand hinaus lesen, und Menschen die Problemdomäne mit ins Spiel bringen sowie längst verdrängte Erinnerungen wie aus ihrem Gedächtnis hervorkramen. Das nennt sich Neudeutsch „Human-in-the-Loop“ und bedeutet, dass die LLM-Agenten oft keinen blassen Schimmer haben, was sich tatsächlich hinter dem übergewichtigen Legacy-Code verbirgt.
Hier stehen wir nun und unterteilen die Moderne in zwei Zeitperioden, „vor ChatGPT“ und „nach ChatGPT“. Wer die zukünftige Bedeutung von Softwarearchitekten und Softwareentwicklern bereits nach null konvergieren sieht, muss sich warm anziehen. So schnell wird man uns nicht los.
Zum Schluss sollten Sie sich festhalten, bevor ich Ihnen eine verborgene Wahrheit mitteile. Ganz unter uns und streng vertraulich natürlich: Auch LLMs generieren Legacy-Systeme.
In diesem Sinne viel Spaß mit der neuen Ausgabe, wie immer voll mit von smarten und erfahrenen Menschen geschriebenen Inhalten.
Ihr Prof. Dr. Michael Stal
