Ich bin skeptisch gegenüber Low-Code

• Ich stehe Low-Code skeptisch gegenüber
• In der Softwareberatung treffe ich häufig auf Kunden, die von Werbeversprechen über schnelle Entwicklungszeiten und niedrige Wartungskosten bei Low-Code angezogen wurden
• Es gibt mehrere Gründe, warum diese Kunden am Ende nicht zufrieden sind

Grenzen bei maßgeschneiderten Funktionen

• Low-Code-Lösungen decken etwa 80 % der Unternehmensanforderungen ab, aber die restlichen 20 % lassen sich mit den Standardfunktionen nicht lösen
• Marketingverantwortliche für Low-Code-Tools behaupten, dass sich diese verbleibenden 20 % leicht lösen lassen, in der Praxis ist jedoch erhebliche Anpassung nötig und manchmal ist es gar nicht möglich
• Unternehmen müssen wählen, ob die Standardfunktionen des Tools nah genug an ihren Anforderungen liegen oder ob sie versuchen, das Tool zu hacken, um es exakt an ihren Anwendungsfall anzupassen

Begrenzter Entwicklerpool

• Unternehmen versuchen manchmal, Low-Code-Tools zu hacken, um 100 % ihrer Anforderungen zu erfüllen
• Das Ergebnis ist oft viel maßgeschneiderter Code in einem bestimmten Tool oder in einer proprietären Sprache, den nur sehr wenige Entwickler verstehen
• Statt aus dem großen Pool an Entwicklern für weit verbreitete Open-Source-Sprachen zu rekrutieren, muss das Unternehmen nun Wartungsverantwortliche finden, die stark auf dieses Tool spezialisiert sind

Probleme bei Plattform-Upgrades

• Es ist schwierig, Software zu aktualisieren, ohne dass angebundene Integrationen kaputtgehen
• Low-Code-Tools müssen beliebigen Code für Anwendungsfälle verarbeiten, für die das Low-Code-Tool ursprünglich nicht ausgelegt wurde
• Das sollte sich über strikte API-Verträge lösen lassen, doch in der Praxis sieht man oft, dass maßgeschneiderter Code intern alle möglichen Tricks anstellt

Verwirrende Datenbankstruktur

• Man sieht Unternehmen, die Low-Code-Tools für Prozesse einsetzen, bei denen präzise Analysen unverzichtbar sind
• Schaut man sich jedoch das zugrunde liegende Datenmodell an, ist es kaum nachvollziehbar: Was bedeutet user_attribute_47? Wenn ein Feld in der Anwendung von Seite 1 auf Seite 2 verschoben wird, liegen die Daten dann plötzlich in einem anderen Feld?

Meinung von GN⁺

• Low-Code ist ein vielversprechendes Werkzeug, um die Entwicklung zu beschleunigen und Wartungskosten zu senken, doch im praktischen Einsatz können unerwartete Probleme auftreten.
• Besonders wenn maßgeschneiderte Funktionen benötigt werden oder Entwicklungssprachen genutzt werden, die an ein bestimmtes Low-Code-Tool gebunden sind, wird der Entwicklerpool kleiner und die Wartung schwieriger.
• Upgrades von Low-Code-Tools und die Komplexität der Datenbankstruktur sind wichtige Aspekte, die im langfristigen Projektmanagement berücksichtigt werden müssen.
• Der Beitrag weist auf Punkte hin, bei denen beim Einsatz von Low-Code Vorsicht geboten ist, und liefert interessante Einblicke, indem er eine sorgfältige Bewertung geeigneter Anwendungsfälle empfiehlt.

[ats62]

Ich bin Low-Code gegenüber skeptisch.

Ich denke, dass das bisherige No-Code-Konzept nur begrenzt in bestimmten Bereichen angewendet wird.

Wenn mit LLMs gut gemachte Services auf den Markt kommen, habe ich eher den Eindruck, dass sich zuerst der Trend? die Strömung? die Richtung? jedenfalls das Konzept von No-Code verändern wird.

[quack337]

Ich kenne einen Fall, in dem MS Access vor etwa 10 Jahren sinnvoll eingesetzt wurde.

Im Informationssystem der Organisation gab es eine vergleichsweise gut entworfene und auf MS SQL Server implementierte Datenbank,
und auch die alltäglichen OLTP-Aufgaben waren ebenfalls relativ gut umgesetzt.

Allerdings hatte sich Unzufriedenheit über die langsame und wenig engagierte Reaktion der IT-Abteilung auf Anforderungen nach nicht alltäglichen Datenabfragen und dem Ausgeben von Berichten angestaut.

Ein Mitarbeiter aus dem Fachbereich, der sich gut mit MS Excel und Access auskannte, zeigte, dass sich durch den Import der aus dem Informationssystem heruntergeladenen Excel-Daten in Access die benötigten Funktionen für Datenabfragen und Berichtsausgaben ganz ohne Programmierung in nur wenigen Stunden mit Access umsetzen ließen.

[quack337]

Die Fachabteilung bat darum, direkt aus Access eine Verbindung zur DB herstellen zu können, und die IT-Abteilung lehnte es ab, die DB des Informationssystems einem externen Netzwerk auszusetzen. Da die Anforderungen der Fachabteilung jedoch sehr nachdrücklich waren, wurde eine separate, gespiegelte DB erstellt und nach außen freigegeben, die nur einige Daten enthielt.

Mitarbeitende, die die Datenfunktionen von Excel gut beherrschten, begannen nach nur wenigen Tagen Schulung, Access in ihrer Arbeit einzusetzen.

[tequila]

Ich kann diesen Beitrag gut nachvollziehen. Das ist nur meine persönliche Meinung, aber
wenn eine spezielle Syntax verwendet wird -> braucht man eine Lernkurve, und die Wartung wird schwieriger
wenn Code nur schlicht durch eine UI ersetzt wird -> ist es oft bequemer, einfach direkt zu programmieren
wenn es zu einem vollständig No-Code-Tool wird -> gibt es viele Einschränkungen, und Nutzer werden zum Hacken verleitet. Die Häufigkeit von Nutzern, die sich anders als beabsichtigt verhalten, nimmt stark zu
Ergebnis: Es wird ein Tool, mit dem niemand zufrieden sein kann.
Die Lücke zwischen Planung, Entwicklung und Nutzern ist gegenseitig einfach zu groß, daher scheint es ein Bereich zu sein, der schwerer gut umzusetzen ist, als man denkt.

[GN⁺]

Hacker-News-Meinungen

• Verschiedene Perspektiven auf Low-Code

  • Perspektive eines Entwicklers von Low-Code-Plattformen

    Low-Code lässt sich leicht verkaufen. Man nutzt eine Strategie, bei der die IT-Abteilung als Problem dargestellt und bestehende Unzufriedenheit ausgenutzt wird. In Demos werden einfache Aufgaben schnell gezeigt. Es ist jedoch besser, die zentrale Geschäftslogik nicht in Low-Code abzubilden. Dabei wird davon ausgegangen, dass komplexe Aufgaben an spezialisierte Systeme ausgelagert werden. In großen Unternehmen ist es nützlich für Teams mit technischem Wissen, aber wenig IT-Befugnissen. Low-Code löst mit einfachen Werkzeugen viele Probleme, skaliert aber schlecht und muss mit starken zentralen Systemen zusammenarbeiten.

  • Perspektive eines SRE (Site Reliability Engineer)

    Skeptisch gegenüber Low-Code. Es fehlt an Source-Code-Verwaltung und die Dokumentation ist schlecht. Oft ist viel benutzerdefinierter Code nötig, aber die Wiederverwendbarkeit ist gering. Proprietäre Runtime-Anforderungen erschweren zudem das Monitoring. In der Praxis sieht man selten, dass Engineers die Arbeit erledigen und Nicht-Engineers das Ergebnis nutzen. Tools wie Looker lassen sich zwar in Source Code integrieren, werden aber trotzdem von Engineers genutzt. Es komprimiert Komplexität, aber bevorzugt werden Plattformen, die sich bei Bedarf anpassen und erweitern lassen.

  • Perspektive auf Microsofts Low-Code-Plattformen

    Es bestand Interesse an den Low-Code-Plattformen von MS, aber sie wirken wie etwas, das kompliziert auf O365 und Azure aufgebaut ist. Die Benutzeroberfläche ist schwach, und langfristig könnten die Verluste durch Usability-Probleme größer sein als die eingesparten Kosten.

  • Geschäftserfahrung mit der Migration von MS-Access-Datenbank-/Formularlösungen

    Es wurde ein Geschäft aufgebaut, das von Nicht-Entwicklern/Endnutzern ohne Einbindung der IT-Abteilung erstellte MS-Access-Lösungen in echte .net-Client/Server-Anwendungen überführt. Low-Code-Lösungen sind nützlich, um bestimmte Probleme zu lösen oder einen POC zum Laufen zu bringen, können aber Probleme verursachen, wenn Skalierung oder Anpassungen nötig werden.

  • Perspektive eines Entwicklers des Website-Builders SQLPage

    Low-Code-Lösungen sollten einen Ausweg bieten, um mit externen „High-Code“-APIs zu interagieren. SQLPage bietet das über sqlpage.exec. Es gibt das Problem, dass Upgrades von Low-Code-Plattformen benutzerdefinierte Implementierungen zerstören können. Die meisten Low-Code-Tools nehmen die Daten als Geisel, aber SQLPage fügt nur eine Ebene auf einer Datenbank hinzu, die der Nutzer weiterhin vollständig kontrollieren kann.

  • Gegenposition zu Low-Code-Tools auf Unternehmensebene

    Ablehnung von Low-Code-Tools, die in Großunternehmen eingesetzt werden. Große Unternehmen sollten in der Lage sein, geeignete Entwicklungsteams, Planung und Organisation zu finanzieren. Nicht Code selbst verursacht Kosten, sondern schlechte Entwickler, die schlechte Tools nutzen und schlechte Entscheidungen treffen.

  • Perspektive auf Low-Code und Abstraktionsebenen

    „Low-Code“ bedeutet zwar, dass die direkt zugängliche Code-Oberfläche kleiner ist, tatsächlich bleibt aber viel Code verborgen. Abstraktionsebenen sind mächtig, wenn sie gut zum Zweck passen, können aber Probleme verursachen, wenn sie lecken oder ungeeignet sind. Im Allgemeinen abstrahiert Low-Code Code für bestimmte Anwendungsfälle, in der Praxis ist dafür jedoch oft Erfahrung in einer bestimmten Domäne nötig.

  • Erfahrung mit dem Aufbau eines MVP mit Bubble/Airtable

    Es wurde ein Angebot eines ukrainischen Teams für den Bau eines MVP eingeholt, stattdessen wurde ein Praktikant eingestellt, der das Produkt mit Bubble/Airtable in zwei Monaten erstellte und innerhalb von sechs Monaten zahlende Kunden gewann. Fast zwei Jahre lang gab es keinen Grund, auf einen traditionellen Stack umzusteigen.

  • Horrorgeschichte aus der Entwicklung eines Low-Code-Lernkurses

    Ein wichtiges Unternehmen entwickelte mit einem Low-Code-Softwarepaket zur Erstellung von Lernkursen interne Schulungen für Marketing- und Vertriebspersonal. Einige Jahre später mussten die Kurse aktualisiert werden, aber weder die damals verwendete Software noch Werkzeuge zur Ausführung der Arbeit waren noch verfügbar, was zu Problemen führte.

  • Frage zur Versionsverwaltung von Low-Code-Implementierungen

    Es wird infrage gestellt, ob sich Low-Code-Implementierungen in eine Versionsverwaltung aufnehmen lassen, ob man bei Problemen die Ursache finden kann und ob sich mit kostenlosen Tools auf einen bestimmten Commit zurückrollen lässt. In den meisten Fällen fehlen diese Funktionen, weshalb sie für ernsthaften Einsatz ungeeignet sind.