Developers sind besser mit No-Code

Vor Kurzem bat mich einer unserer Kunden, in ihr Middleware- und Integrationstool (Xentral Connect) einzutauchen, um mehr Redundanz in dem Team zu schaffen, welches die bestehenden Workflows verwaltet. Der erste Eindruck war recht angenehm. Ich war bereits mit dem allgemeinen Konzept von Enterprise-Middlewares vertraut und habe viel Erfahrung im Umgang mit Message Queues wie RabbitMQ und Datenbanken. Mit einer solchen Middleware-Software kann man verschiedene Quellen anbinden, Daten abrufen (oder von Quellsystemen pushen lassen), sie an einem zentralen Ort speichern und an verschiedene Zielsysteme weitergeben (oder den Zielen erlauben, die Daten abzurufen).

Automatisch begann mein Gehirn über die Implementierungsdetails der Software nachzudenken: Wie werden Datenstrukturen gespeichert, nachdem Benutzer:innen sie in der UI erstellt haben? Wie werden Joins zwischen Datenstrukturen ausgeführt? Was steckt hinter UI-Flags wie "Index" und wie beeinflussen sie die bestehenden Daten in einer Datenstruktur, wenn die Flags umgeschaltet werden? Nach ein wenig Herumprobieren wurden die Antworten offensichtlich: Datenstrukturen werden zu Tabellen in einer Datenbank, und Filteroperationen werden in Standard-SQL-ähnliche WHERE-Abfragen übersetzt. Das Index-Flag an einer Spalte wird zu einem Datenbankindex, der viel schnelleres Filtern nach der entsprechenden Spalte ermöglicht.

Diese Erkenntnisse halfen mir, einen leistungsfähigeren Workflow zu erstellen, der indizierte Spalten für Suchen verwendet und bewährte Praktiken aus dem Systemdesign wie idempotente Nachrichten, At-Least-Once-Delivery und Delta-Loading einsetzt. Hätten Nicht-Entwickler:innen das gleiche Ergebnis erzielen können? Vielleicht. Doch eines ist sicher: Diese No-Code-Tools haben ihre Grenzen. Aus diesem Grund bieten alle von ihnen die Möglichkeit, benutzerdefinierte Code-Schritte hinzuzufügen. Und sobald jemand diese Schritte nutzt, wird er oder sie mehr oder weniger automatisch zu Entwickler:innen, auch wenn keine IDE verwendet wird, sodass die gleichen Erfahrungen gemacht werden müssen, um das Handwerk zu erlernen.

Diese Erfahrung machte mir klar, warum ich als Entwickler keine Angst vor No-Code-Tools, KI oder anderen Buzzwords habe, die das Ende der Softwareentwicklung versprechen. Als Entwickler:in lernen wir Prinzipien, die für alle Programmiersprachen und Softwarelösungen gelten. Und indem wir diese Prinzipien weiterhin verstehen, werden wir zu besseren und effizienteren Nutzer:innen von Ansätzen, die diese Details unter Abstraktionsebenen verbergen. Vielleicht sieht unser Beruf in 20 Jahren etwas anders aus, vielleicht tippen wir dann keine Zeichen und Worte spezialisierter Programmiersprachen mehr in einen Editor, aber wir werden weiterhin unser Verständnis für die Modellierung der realen Welt in technischen Systemen einsetzen.