Low-Code-Plattformen versprechen, dass Menschen ohne Programmierhintergrund eigene Anwendungen bauen können. Das funktioniert erstaunlich oft. Interessant wird es an der Stelle, an der es nicht mehr rein deklarativ geht.
Üblicherweise wird hier binär gedacht: Entweder jemand schreibt Code oder eben nicht. Beim Durcharbeiten des Themas bin ich zu dem Schluss gekommen, dass diese Grenze an der falschen Stelle liegt. Sinnvoller sind drei Stufen: rein deklarativ zusammenklicken; fremden Code einbinden, ohne ihn zu verstehen; eigenen Code schreiben.
Die dritte Stufe ist die anspruchsvollste, aber nicht die gefährlichste. Wer selbst schreibt, hat den Preis dafür bezahlt, es zu verstehen. Das Risiko sitzt auf der mittleren Stufe. Dort wird ein Ergebnis erzielt, ohne dass jemand nachvollziehen kann, wie es zustande kommt – und damit fällt der Soll-Ist-Vergleich weg. Wer nicht weiß, was passieren soll, kann nicht erkennen, dass etwas anderes passiert.
Die Lernkosten verschwinden dabei nicht. Sie wandern nur: aus der Lernzeit in die Wartbarkeit. Sichtbar wird das erst Jahre später, wenn jemand anderes den Fehler suchen soll.
Und genau hier wird es aktuell. Ein Code generierender KI-Assistent wird gern als das Werkzeug beschrieben, das die Programmierschwelle endgültig einreißt. Nach dieser Lesart tut er etwas anderes: Er hebt die Schreibschwelle nicht auf, er verbreitert die Auffahrt auf die mittlere Stufe. Ergebnis ohne erzwungenes Verständnis, in größerem Umfang und schneller als vorher. Das Wartbarkeitsproblem wird dadurch eher größer.
Das ist kein Argument gegen Low-Code und keins gegen Assistenzsysteme. Es ist eher ein Vorschlag, worauf man schauen sollte, wenn man beides einführt: nicht darauf, wie viel Code jemand schreibt, sondern darauf, ob irgendjemand den Code erklären kann, der dort läuft.
Leseempfehlungen
- Alexander C. Bock, Ulrich Frank: Low-Code Platform, Business & Information Systems Engineering 63(6), 2021 – kurz, pointiert, und mit dem Befund, dass Low-Code eher ein Marketinglabel als ein tragfähiger Fachbegriff ist. doi.org/10.1007/s12599-021-00726-8
- Gerhard Fischer, Elisa Giaccardi, Yunwen Ye, Alistair Sutcliffe, Nikolay Mehandjiev: Meta-design. A manifesto for end-user development, Communications of the ACM 47(9), 2004 – über zwanzig Jahre alt und immer noch der beste Text zu der Frage, warum Fachleute ihre Werkzeuge selbst formen sollten. doi.org/10.1145/1015864.1015884
- Hans van Vliet: Software Engineering. Principles and Practice, Wiley, 3. Auflage 2008 – für den Überblick, wie Abstraktion und Wiederverwendung im Entwicklungsprozess eingesetzt werden und welche Prozessmodelle es dafür gibt. Begleitseite des Autors
Dieser Text geht auf eine Seminararbeit zurück, in der ich mich mit Low-Code-Entwicklung durch Nicht-Programmierer beschäftigt habe. Was hier steht, ist meine Einordnung aus Literatur und Gesprächen – keine belastbare Studie, und die Beispiele sind bewusst allgemein gehalten.