Immer wieder kommt in unserer Branche eine vielversprechende, bahnbrechende Neuerung um die Ecke: Themen wie Industrie 4.0 oder aktuell Künstliche Intelligenz finden viel Aufmerksamkeit. Und gerade künstliche Intelligenz – korrekterweise machine learning – löst bei einigen eine große Hypestimmung, bei anderen große Angst aus. Ein beliebtes KI-Szenario: die Arbeit von Entwickler:innen zu übernehmen. Und so soll auch Low-/No-Code jeden ermächtigen, Entwicklungsarbeit zu vollbringen, ohne über tiefgreifendes Wissen oder Fertigkeiten zu verfügen.
Angetan von dem Versprechen, leichter und schneller zu einem MVP zu kommen – also Wert auf Kundenseite zu schaffen – haben wir uns das Ganze mal genauer angeschaut.
No-Code beschreibt ein Tool, mit dem ein:e Nutzer:in eine Anwendung entwickeln kann, ohne selbst auch nur eine Zeile Code schreiben zu müssen. Es sind keinerlei Vorkenntnisse notwendig, um mit der Arbeit zu beginnen. Im Gegensatz dazu besteht bei Low-Code die zusätzliche Möglichkeit, komplexere Programmabläufe auch mithilfe von Code umzusetzen. Das bedeutet aber auch: Es müssen zumindest grundlegende Programmierkenntnisse vorhanden sein.
Die meisten Anbieter von Low-Code oder No-Code Lösungen bieten ein Rundumsorglos-Paket an. Das heißt, sie verwalten den “Code”, halten Dependencies auf dem aktuellen Stand, hosten die fertige Anwendung sowie eine Testumgebung. Und sie bieten einen gemeinsamen Ort für Design und Entwicklung, von Frontend über Logik bis Datenhaltung. Normalerweise sind für all diese Aufgaben eine Menge qualifizierter Entscheidungen von Fachleuten nötig. Diese Anbieter versprechen, diese Entscheidungen abzunehmen.
Der größte Vorteil, den Low-/No-Code zu “normaler” Softwareentwicklung verspricht, ist die erhöhte Entwicklungsgeschwindigkeit. Insbesondere die Zeit von Idee bis testbarer MVP soll auf ein Minimum reduziert werden.
Manche Anbieter machen auch sehr mutige Versprechen. Beispielsweise verspricht Thinkwise mit “Infinite technological lifespan” eine unendliche technologische Lebensspanne der fertigen Anwendung. Ist das überhaupt möglich? Denn es gibt durchaus Faktoren, die der Anbieter nicht in der Hand hat. So können sich verwendete APIs mit der Zeit grundlegend ändern. Oder es muss zum Schließen einer Sicherheitslücke eine Dependency so stark angepasst werden, dass es einem Anpassen der Geschäftslogik bedarf, um sie weiter verwenden zu können. Solche Probleme kann der Anbieter dem Nutzer nicht abnehmen, da er die Geschäftslogik gar nicht kennt.
Und natürlich kann aufgrund der großen Abhängigkeit zum Anbieter die Software den Anbieter nicht überdauern, bzw. ist der Umzug zu einem anderen Anbieter mit einem großen Aufwand verbunden.
Zuerst: auch Low-/No-Code muss man lernen. Und dabei sollte man auch auf die richtige Wahl achten. Wir hatten schon Erfahrungen mit zu begrenztem Funktionsumfang gemacht und wollten sichergehen, dass unser Ergebnis nicht von unserer Auswahl abhängt. Deshalb haben wir uns eine Liste von unterschiedlichen Tools herausgesucht und in vier Kategorien unterteilt, da jeder Anbieter einen anderen Fokus legt. Die Kategorien waren “Datenspeicher”, “Logik”, “Frontend” und “Full Service” und die herausgesuchten Tools, waren “Airtable”, “Zapier”, “Make”, “Retool”, “Zappter”, “Bubble.io”, “SAP Build”, “Adalo” und “Thinkwise”.
Unser Produkt: ein Timer für unseren monatlichen Info-Hub-Termin.
Dauerte ein Versuch mehr als einige Stunden, wurde er abgebrochen und als Fehlschlag gewertet.
Eine erste Erkenntnis gleich zu Beginn: Tools wie “Airtable”, “Zapier” und “Make” waren für unsere Aufgabe vollkommen ungeeignet, da sie auf das Verarbeiten von Daten spezialisiert sind. Sie sind deshalb von der Wertung ausgenommen.
Unser Meeting-Timer muss mit “Zeit” umgehen, dies lässt auch in allen gängigen Programmiersprachen viele Entwickler verzweifeln. Eine gute Aufgabe also, und daran ist es dann auch bei den meisten Tools gescheitert: entweder das Verwenden genauer Uhrzeiten oder das Darstellen des aktuellen Zählerstandes war nicht möglich.
Lediglich mit “Bubble.io” konnten wir unser Ziel - innerhalb dem uns gesetzten Zeitlimits - erreichen.
Das Ergebnis hat etwa 2 Stunden in Anspruch genommen. Natürlich gäbe es noch einiges mehr zu tun: Minuten darstellen, bei Ablauf des Timers einen Alarm abspielen, und auch die Gestaltung anpassen.
Am Rande: Bei “SAP Build” sind wir gar nicht so weit gekommen, allein das Erstellen eines Accounts und Beantragen einer Testumgebung kostete mehr Zeit, als wir uns gegeben hatten.
Kurz gesagt: nicht so, wie wir es uns erhofft haben.
Ja, die Anbieter bieten einem ein Rundumsorglos-Paket. Und ja, etwas Benutzbares ist innerhalb von Minuten in einer Testumgebung gehostet, die sich auch mit anderen teilen lässt. Um diesen Komfort aber bieten zu können, müssen die Anbieter massiv Komplexität einsparen. Das lernten wir leider oft erst mitten auf dem Weg. Viele Anbieter haben ein Tutorial oder vielfältige Templates, mit denen sich schnell etwas Ansehnliches bauen lässt. Weicht man von diesen ab und möchte ein reales Problem lösen – das doch nie so einfach ist wie die Beispiele – stößt man schnell an eine Grenze oder landet wieder bei vollwertiger Softwareentwicklung, die ohne entsprechende Vorkenntnisse kaum möglich ist. Auffällig ist auch, dass die Templates oft für simple Webseiten gedacht sind, Blogs, Shops usw. Doch für solche Webseiten gibt es schon lange viel bessere Tools, die sich darauf spezialisiert haben. Stößt man mit diesen Tools an Grenzen, sollte Low-/No-Code einen weiterbringen. Und das tut es leider nicht.
Ist Low-/No-Code also ideal, wenn man genau weiß, was man will? Nein, Low-/No-Code ist eher vergleichbar mit Excel, wobei Low-Code einer normalen Excel entspricht und Low-Code Excel mit Visual Basic Code Fragmenten. Und wofür Excel ideal ist, ist gemeinhin bekannt, “Quick and Dirty” Lösungen für kleine Probleme, die schnell wieder verschwinden oder von einer hochwertigen und individuellen Softwarelösung ersetzt werden sollten. Das kostet mehr, schafft aber auch mehr Wert.
Der schnelle Einstieg ist ein klarer Vorteil von Low-/No-Code Lösungen, jeder kann mit einer Produkt-Idee einfach mal loslegen. Dass dabei aber etwas Brauchbares herauskommt, halte ich für unwahrscheinlich. Das Wichtigste für den Erfolg einer Idee ist es erst einmal in Ruhe zu planen, was man möchte und wie es genau funktionieren soll. Einige Ideen stellen sich dabei schon als unsinnig heraus, andere entwickeln sich in eine ganz andere Richtung als gedacht. Dazu empfiehlt sich unser Blog über initiale Workshops.
Andreas und Benjamin haben für diesen Post Ihre Sichten als Entwickler und UX-Designer zusammengeworfen. Beide sind gespannt, wo Ihnen zukünftig das Thema Low-/No-Code hilft, Wert zu schaffen.