Du möchtest das Video an jemanden weiterleiten, die oder der aber lieber liest? Dann findest Du den passenden Artikel zum Video bei Heise Developer: www.heise.de/blog/Low-Code-Co-Mehr-Schaden-als-Nutzen-10184237.html
ich bin Software-Entwickler (C#) im Rahmen von Microsoft Dynamics CRM. Ich schreibe regelmässig Plugins in C# und "kämpfe" immer wieder mit den nicht ganz-so-technischen Kollegen, welche Low-code-Plattformen in den Himmel loben. Der Weg, den wir jetzt gefunden haben, ist der, dass ich mittels C# Bausteine für Low-Code-Plattformen entwickle, welche dann von den Fachabteilungen verwendet werden können. So können viele Vorteile der Low-Code-Plattform genutzt werden und dennoch habe ich im Hintergrund die Möglichkeit verschiedene technische Einschränkungen/Eigenheiten etc. "sauber" lösen zu können.
Ich glaube das ist ein durchaus praktikabler Ansatz. Aber frage mich schon ob es diesen großen Individualismus in vielen Unternehmensprozessen durch LowCode überhaupt braucht. Also ob man sich langfristig damit nicht erst wieder Aufwände schafft die bei langsamerer Individualisierung durch echte Entwicklung von vornherein vermieden werden könnten. Stichwort Berechtigungsmanagement, Kompatibilität usw.
@@dominik4496 Genau - ich höre bei uns immer wieder das Argument, dass Low-Code halt schneller/günstiger sei. Allerdings nur kurzfristig - weil eben auf längere Sicht immer wieder die gleichen Themen auftauchen (Stichwort Kompatibilität und Erweiterbarkeit). Klar muss nicht jede Individualentwicklung bis ins letzte Zeichen konfigurierbar sein - aber ein gesunder Mittelweg zwischen Flexibilität und Stabilität bringt mittel- und langfristig am meisten Nutzen. Leider kostet dieses Vorgehen im ersten Moment etwas mehr Ressourcen, weshalb wir als Entwickler in vielen Fällen einen schweren Stand haben, dies zu rechtfertigen (sofern die Entscheidungsträger keine Entwickler sind). Wenn es nachher dann doch noch verändert werden muss, sollte dies am besten noch "gratis" passieren, weil "wir es ja am Anfang nicht richtig" gemacht haben 😞 Da helfen mir Low-Code-Plattformen und die von mir entwickelten Schritte dafür: Es ist einfacher zu argumentieren, dass ein kleines Plugin in sich geschlossen ist und eben nicht erweitert werden kann, als eine vollständige Applikation.
@@MarkusH87 Dann öffne ich den Editor, und erweitere die LowCode-Anwendung. Wenn immer wieder die gleichen Themen auftauchen, setze ich ein Modul auf Public und kann es in den anderen Applikationen nutzen.
@@RaveKev "Wenn immer wieder die gleichen Themen auftauchen, setze ich ein Modul auf Public und kann es in den anderen Applikationen nutzen." Das machen 5 deiner Kollegen aber auch. Aber gut, dann hast du nach ein paar Jahren wenigstens ein gutes dutzend Module zur Feiertagesermittlung (International), Feiertagsermittlung (DACH), Feiertagsermittlung (DACH-Ohne-BW) und Feiertagsermittlung (Uwe, bis Q42027, V17 ohne Foo). Da ist bestimmt was passendes dabei. 🙂
@@lupf5689 Wo genau ist da der Unterschied zu anderer Softwareentwicklung? Wenn die Firma ein Problem hat, Dinge zu planen bzw. geordnet zu nutzen wird sie es mit jeder Sprache haben. Oder soll ich mal schauen, wie viele Nuget, NPM oder andere Bibliotheken es gibt, die sich mit der Feiretags-Thematik befassen?
Eine sehr treffende Zusammenfassung! Ich lasse die Low-Code-Enthusiasten gerne ihre Ansätze ausprobieren - oft zeigt sich bei wachsender Komplexität, dass die Grenzen schnell erreicht sind. Häufig höre ich dann von Projektverantwortlichen, dass die neue Indiv-Entwicklung jetzt sehr kostengünstig umgesetzt werden muss, nachdem der Low-Code-Ansatz gescheitert ist und schon viel Budget verschlungen hat. Es ist interessant zu sehen, wie schwer es manchmal ist, diesen Punkt im Voraus zu vermitteln, auch wenn man es bereits beim ersten Meeting anspricht.
Spannenderweise ist das bei unseren Kunden häufig anders. Da steht eine Softwarelösung die in HighCode geschrieben wurde und auf einmal bricht die Abteilung oder die Firma, die das System umgesetzt hat weg. Dann steht man da (quasi ein VendorLock). Dann müssen sich Leute nochmal komplett einarbeiten und die Software neu schreiben. Dass man dann auf LowCode umsteigt ist aufgrund der benötigten Zeit mit HighCode eine nicht zu unterschätzende Möglichkeit. Man kann Leute, welche bereits Erfahrung in Programmiersprachen haben, sei es auch "nur" JavaScript oder so, sehr schnell darin enablen und an den Projekten arbeiten lassen.
Es ist wie immer. Es kommt darauf an das passende Werkzeug und die passende Person für die Aufgabe auszuwählen. Je besser dies gelingt, desto besser ist das Ergebnis. Verschiedene Konstellationen können da gleichermaßen zum Ziel führen.
Grundsätzlich ist der Low Code Ansatz ok. Aus eigener Erfahrung (ich arbeite inzwischen gut 4 Jahre damit) muss ich sagen, dass die von uns verwendete Plattform von einem Fachbereich selbst unmöglich verwendet werden könnte. Dazu braucht es allen Versprechungen zum trotz erfahrene Programmierer, wie die aus meiner Abteilung. Denn man muss letztlich Grundlagenwissen wie OOP, Datenbankverständnis, Netzwerk, je nach dem auch Speichermanagement, und und und. mitbringen. Halt alles Basics, die ein Programmierer kennen muss, egal welche Art von Sprache er programmiert. Daher ist die Programmierung eines einfachen Tools zwar meist relativ schnell erledigt. Aber sind erst mal Begehrlichkeiten geweckt und es gibt Erweiterungen oder Spezialisierungen, dann nimmt auch der Zeitaufwand zu, und der Vorteil solcher Plattformen nimmt im Verhältnis ab.
Das Problem wurde schon vor über 50 erkannt und mit Generatoren zu beheben versucht. In den 80er/90ern entstanden extrem fortschrittliche grafische Tools, die verschiedene Abstraktionsebenen nutzen und synchron halten konnten - alles vergebens: Die Schwierigkeiten mit unbestimmten, wechselnden, widersprüchlichen und nicht abgestimmten Fachanforderungen waren nie in den Griff zu kriegen.
Alles, was man mit einem Generator hinbekommt kann man auch mittels einer Library bauen. Eine lib ist einfacher zu pflegen, DRY Pattern. Der Traum nach den Generatoren geht ungebremst weiter und es scheitert fast immer.
Ich bin auf der Verkauf-den-Krams-Seite und mein Sourcerer hat mich hierher geschickt. Schon länger nicht mehr so klare Ansagen gehört. Vielen Dank! :)
Habe vor einer Weile mit Apache Camel Karavan arbeiten müssen. Das war gut um den Kunden ein Projekt aufzuschwatzen, wo sie ganz einfach selber dran arbeiten können, ohne viel von Camel zu wissen. Oftmals will man dann aber doch mehr umsetzen und das war mit der Low Code Lösung einfach lästig/nervig, sodass man argumentiert hat "Wenn es ein reines Camel Projekt wäre, würde alles viel schneller gehen". Also letztlich ein Marketing Tool.
Was für wahre Worte, mein Lieber, es geht nur mit einem Miteinander. Ein gemeinsames Ziel zu erreichen. Zusammen, das beste Produkt erschaffen, was unser Kunde braucht. Was uns legitimiert das zu tun, was wir tun.
Naja kann man inzwischen sicher auch als Person im Einkauf etc. einfach ein LLM machen lassen. Einfach sagen ich brauche XY, schreibe mir einen Code und sage mir was ich machen muss, damit dieser läuft und dann hat sich das, bis der erste Bug auftritt. Das wird noch ein Spaß werden, sage ich euch!
Das möchte ich sehen, dass ein Nicht-Entwickler ausschließlich mit Hilfe von ChatGPT eine lauffähige Anwendung abseits einer trivialen Web-App baut. Ohne ein Verständnis davon wie Software funktioniert ist man gar nicht in der Lage Promts so spezifisch zu formulieren dass die Software das macht was man möchte.
Hab selbst einige Jahre in einem Unternehmen gearbeitet, welches die Programmierung eines neuen IT Projektes an einen Dienstleister gegeben hat, der auf Low-Code gesetzt hat. Aus meiner Erfahrung sind die Platformen für große Projekte komplex, dass man trotzdem "Programmierer" braucht, benötigte nicht Standardfunktionaliäten werden mit aufwändigen Workarounds umgesetzt, Unternehmen binden sich an Plattformunternehmen und deren Überleben, aus Softwaretestsicht sind die Umsetzungen graußam. Daher für kleine Unternehmen die eine kleine Softwarelösung brauchen, kann Sinn machen, für alles andere lieber nicht.
Low-Code Plattformen sind m.E. auch nur als Framework zu verstehen. Sie nehmen einem Arbeit ab, genauso muss man aber man aber auch verstehen, wo die Limitierungen liegen. Wir nutzen für unsere Kundenprojekte Pro-Code & Low-Code Lösungen. Je nach Anforderung bzw. Anwendungsbereich entscheiden wir uns für die Plattform die am meisten Sinn macht.
ich habe vor einigen monaten eine facharbeit zum thema low-code/no-code bei sap build apps geschrieben, wo analysiert wurde, ob nicht-entwickler nach einer vorher durchgeführten schulung damit eigenständig etwas entwickeln können...das ergebnis war: keine chance ohne programmierkenntnisse...es ist für fachanwender viel zu komplex...stichwort: API-anbindung
Diese Erkenntniss habe ich selbst bei mir erlebt. Nun lerne ich wirklich die Basics und will erstmal da rein kommen bevor ich mir so was überlege. Das Stichwort mit API Anbindung ist gut
Auf den Punkt! Für Prototyping, damit die Fachabteilung ihre eigenen Prozesse definieren kann sehr gut geeignet. Für mehr aber auch nicht. Ein Marketing-Produkt, genau wie die Meinung, dass KI jetzt alles schneller, besser und einfacher löst. Leider fallen darauf viele Entscheider herein. Problem sind hier die Berater und die HR Leute, egal ob im Personalbüro oder die Projektvermittler. Leider haben diese vom fachlichen keine Ahnung und geben sich auch wenig Mühe. Mir kommt es manchmal so vor, als würden die als Verkäufer in einem Autohaus arbeiten, haben aber nicht mal das Prospekt gelesen. IT ist auch Fachwissen, deren Grundkenntnisse in den Fachbereich gehören, so wie Entwickler Kenntnisse aus dem Fachbereich haben müssen.
Tja, ich weiß nicht so genau. Ich bin selber für die öffentliche Verwaltung tätig. Hier steht man immer wieder vor eher leichten und immer sehr ähnlichen fachlichen Prozessen: Ein Antrag wird gestellt, irgendwer muss seinen Stempel drunter machen, jemand muss eine Entscheidung treffen, jemand muss ein Datum ergänzen, irgendetwas muss irgendwo hin archiviert werden, am Ende ist der Antrag durch und geht zurück an den Antragsteller, vielleicht wird zwischendurch mal ein Nachbarsystem angefragt. Und zumindest GUI-seitig sehen die entsprechend alle sehr ähnlich aus und auch die Datentöpfe hinten dran sind jetzt nicht unbedingt speziell. Da fragt man sich ja: Warum muss für jeden dieser Fachanwendungen wieder eine neue Angular Anwendung gebaut werden, die auch entsprechende Wartung braucht? Warum kann ich mir die passenden Masken nicht einfach entsprechend zusammenklicken oder gar aus vorliegender BPMN generieren lassen? Und genau das scheinen Low-Code Plattformen ja anzubieten, klingt also nicht unplausibel. Andererseits hört man kaum Erfolgsgeschichten aus dem Bereich und Vendor Lock In möchte man auch nicht so gern. Schwierig zu sagen, was da jetzt richtig ist...
Ich bin ein riesen Fan deiner/eurer Videos und teile sie regelmäßig in unserer Firma. Allerdings lässt mich das Video einigermaßen sprachlos zurück - gerade in Hinsicht auf die letzten Worte zum den "Wir-gegen-die"-Ansatz. Werde es trotzdem versuchen einiges dazu zu schreiben. Ich bin seit 2008 Java-Entwickler aber seit 4 Jahren als Low-Code-Entwickler (OutSystems) unterwegs. Eins vorweg: auch wir sehen den Citizen-Developer-Ansatz noch etwas kritisch wegen der von dir beschriebenen Probleme. Es gibt natürlich unterschiede der verschiedenen Plattformen wie PowerPlattform, Appian, Mendix oder OutSystems. Da ich OutSystems-Entwickler bin (ja, man kann Entwickler darin sein - es ist ja schließlich keine NO-Code-Plattform), werde ich größtenteils das Thema aus dieser Sicht beschreiben. Und ohne anderen zu nahe treten zu wollen, bin ich wirklich froh, bei OS gelandet zu sein, statt einer der anderen Plattformen. Denn: Wir sind eine Consulting-Firma deren größter Teil die Entwicklungsdienstleistung mit C# oder OutSystems ist. Die dem LowCode häufig vorgeworfenen MickeyMaus-Applikationen mit ein paar Eingabemasken sieht man zwar auch, aber die Software an der wir arbeiten sind große, firmenkritische Anwendungen, die teilweise auch der Dreh-und-Angelpunkt des Geschäftes werden. Mit einer gehosteten LowCode-Plattform bleiben für Kunden die Wartungsarbeiten erspart, und man kann sich auf die Entwicklung stürzen, welche wirklich nur einen Bruchteil der Zeit benötigt. Wenn andere Entwickler in ein Projekt kommen, ist die Einarbeitungszeit um einiges schneller, da man den Code durch die optische Entwicklung und standardisierte "Knoten" auf ein paar Blicke verstehen und sich auskennen kann. Der Vendor-Lock ist natürlich teilweise vorhanden, wird aber bei OS dadurch aufgeweicht, dass man sich den generierten Quellcode (JavaScript sowie .Net-Code) beim Kündigen des Vertrages bereitstellen lassen kann. Man könnte also auch danach noch etwas weiter an der Software entwickeln (wie sinnvoll das ist, ist dahingestellt, da der Code zwar menschenlesbar ist, aber nicht suuuuuuuper intuitiv). Die Punkte, die hier vorgeworfen werden sind, wie wenn man Affinity Designer oder Adobe Illustrator vorwerfen würde, dass sie mies sind, da jetzt jeder Abteilungsleiter Logos und Grafiken erstellen könnte. Ja, kann man ABER das ist nicht unbedingt das Ziel. Nicht umsonst ist hat OutSystems einen Rahmenvertrag für die Öffentliche Hand erhalten, wodurch es Kommunen der gesamten Öffentlichen Verwaltung einfacher gemacht wird, Projekte damit zu starten. Das ganze klingt jetzt natürlich nach Werbung - soll es aber gar nicht sein. Ich für meinen Teil bin einfach mega überzeugt davon WIE und WOMIT ich tagtäglich arbeite und WAS ich für den Kunden abliefere. Wenn ihr möchtet, kann ich euch gerne mal zeigen, wie ich entwickle und ggf. eine kleine Einführung in OutSystems geben,. Nach den ganzen Jahren Java, C# und Angular-Entwicklung fühlt es sich so an, als sei ich angekommen.
Wir haben von OutSystems auf Mendix gewechselt. Leider. Ich empfand OutSystems als einfacher und intuitiver zu bedienen. Aber sogar dort hätte ich Mühe, dieses den Fachbereichen vorzusetzen. Auch wenn es einfacher ist, denke ich, die Fachbereiche sollten sich um ihr Ding kümmern, die IT und gesonderte Entwicklungsabteilungen machen die Applikationen. Schon um eine gewisse Architektur entstehen zu lassen, die letztlich auch wieder Qualität und Aufwand verbessert.
@@reneberger6340 Das ist komplett richtig! Bin auch der Meinung, dass es Entwickler-KnowHow braucht, um langlebige und erweiterbare Software zu schreiben. Wir haben auch einmal getestet, völlig Entwicklungs-Fremde Personen als Quereinsteiger in LowCode zu enablen, was in 75% der Fälle auch gut bis sehr gut lief.
"Wenn andere Entwickler dazu kommen und...." halte ich für ein ziemliches Märchen. Es mag stimmen stimmen solange die Anwendung extrem klein ist. Wenn die Anwendung aber etwas komplexe wird und unzählige Knoten besitze und nicht nur aus einem Prozess sondern 30 dann kippt das ganze. Code ist einfacher zu bearbeiten und zu lesen als sich durch durch die unzählige Quadrate zu scrollen und spätestens beim dritten Bildschirm scrollen die Orientierung verloren zu haben.
@@dd1982bb "beim dritten Bildschirm scrollen die Orientierung verloren zu haben". Auch bei Low-Code gelten Clean Code vorgaben, wie klein gehaltene, dafür sprechend benannte Actions/Methoden.
ich fühl es. Habe eine App nach Bausatzsystem versucht und mein Problem war abseits des vorgegebenen Pfades. Danke, dass ich doch nicht so doof bin ;) Nun lerne ich Java um flexibel zu sein. Somit hatte der Weg seinen Sinn :)
tja. Das Ergebnis suboptimaler Kommunikation zwischen Fachabteilung und IT-Abteilung bzw. Entwicklung kann man täglich beobachten. Die eine Seite weiß nicht, was die andere Seite braucht - und die andere Seite weiß nicht, was die eine Seite aus der Technik herausholen kann - geschweige denn, für welche Probleme sich eine technische Lösung lohnt, und an welchen Stellen eine technische Lösung Abläufe eher verkompliziert oder gar verunmöglicht, wenn nicht alle Eventualitäten des Alltags mitbedacht werden. Also wird einfach geraten, ohne nähere Kenntnis der Materie die Initiative ergriffen, etc. Eigentlich sehr seltsam. 🙂 Aber was man auch beobachten kann: viele sind der Meinung, alles nach bestem Wissen und Gewissen richtig zu machen, während die eine über die andere und die andere über die eine Seite häufig schimpft. 😀 Früher gab es mal so Ausbildungen, in denen man gelernt hat, die Sprache der Kunden und die Sprache der Entwickler zu sprechen und eine Art Schnittstelle zwischen beiden zu bilden. Leider werden die vielerorts offenbar stark unterbewertet.
Für größere oder komplexere Projekte ist lowcode denke ich auch langfristig nichts. Aber für citizen developer, die sich kleinere Sachen basteln, ok, da ist es doch schön, wenn es klappt. Und wenn es nicht klappt, dann wird es auch nicht mehr in den Himmel gelobt werden. Ich mag den Vergleich mit dem Kartenset, mit dem man Sätze legen kann. Das trifft den Nagel auf den Kopf.
Wir gegen die... oh man, wie oft ich das schon in Projekten erlebt habe. Am Ende stehen dann alle irgendwie als Verlierer da, und mit dem Erzeugnis (der Software) will keiner mehr so richtig was zu tun haben - sehr sehr traurig. Zum Thema Low-Code/No-Code: In Bezug auf generische Entwicklungsplatformen würde ich mich deiner Meinung anschliessen, die Sinnhaftigkeit solcher Platformen darf man hier sicher hinterfragen. An anderer Stelle sehe ich aber durchaus eine Berechtigung für Low-Code/No-Code-Ansätze, und zwar dort, wo ich Anwendern explizit eine Anpassbarkeit, aber eben im auch nur im sehr spezifischen Rahmen einräumen will. Low-Code/No-Code also als spezielle Form bzw Erweiterung einer Produkt-Konfiguration.
Die Ansätze, die man heute "Low-Code/No-Code" nennt, gab es schon immer. Wenn ich mich recht erinnere, wurden die früher als "Rapid Prototyping" bezeichnet. Diese Ansätze haben m.E. durchaus ihre Berechtigung und ihren Nutzen. Sie können z.B. mit relativ geringem Aufwand zum initialen "Ausprobieren" von neuen Anwendungs-Ideen dienen, die sonst aufgrund der normalen IT-Entwicklungs-Prozesse niemals angegangen werden würden. Und wenn man dann erstmal was zum "Vorzeigen" hat und seine "Chefs" vom Nutzen überzeugen kann, dann wird ggf. auch ein "richtiges" Entwicklungs-Projekt aufgesetzt. Es ist aber auch hier wie mit allen Sachen im Leben - "Hirn einschalten" und nicht allen flotten Marketing-Versprechen der Hersteller blindlings glauben. 🙂
Im Grunde kann man das tatsächlich mit Rapid Prototyping vergleichen, auch wenn heute die Apps einen produktiveren Ansatz haben. Als mein Chef das damals hörte - kein ITler - war er Feuer und Flamme und meinte, jetzt braucht man ja nicht mehr viel machen. Schon gar nicht dokumentieren oder so.. uff..
Das soll auch unser Ansatz werden, also Low-Code als Prototyping Tool nutzen, um Gelder zu sammeln um große, komplexe Software bauen zu können. Wenn man auch bedenkt, wie viele Leute noch Prozesse mit Excel abbilden, dann wollen wir auch diese Leute zu solchen Plattformen bringen, um dort Gemeinsamkeiten herauszuarbeiten oder schneller einfache kleine Ideen umzusetzen. Wir stehen aber noch am Anfang des Prozesses bei der Suche nach der richtigen Plattform
Ich habe mich intensive mit Low-Code beschäftigt, ich kann diese Aussagen aus diesen Video nur bestätigen. Wenn ich mit einem Vendor mich einlasse, bin ich gefangen. Stoße ich auf Anforderungen, die nicht mit dem Low-Code Produkt umgesetzt werden können (also im Low-Code Produkt berücksichtigt wurde), bin ich gefangen. Also bitte vorher das Low-Code Produkt genau untersuchen, das bedeutet aber wieder Aufwand, der nicht unerheblich sein kann. Also vorsichtig sein.
Einige LowCode-Plattformen bieten es auch an, eigene Extensions per JavaScript (für die Clientseitigen Dinge) oder beispielsweise .Net (für die Serverseite) zu schreiben. Auch Anbindungen an andere Systeme sind so umsetzbar.
Versicherung?? Das macht der Bernd, läuft 😂 Spass bei Seite, low-no-code habe ich viele +/- mitgemacht in den letzten 30 Jahren. Ich finds super, um mit dem user ins Gespräch zu kommen, statt zB Bilderchen malen. Produktiv hab ich da nix gesehen.
Ich arbeite sehr gerne mit nodeRed aber der JavaScript Block ist mein bester Freund. Man könnte aber vieles vermutlich ohne aber dafür minimal komplexer lösen
9 วันที่ผ่านมา +1
Ich musste sehr grinsen beim Anhören dieses Videos. Es gibt halt auch viele kleine Firmen, die vergeblich nach dem netten oder weniger netten Mitarbeiter der IT Abteilung suchen, weil's nämlich überhaupt keine IT Abteilung gibt. Wenn man dann kleinere Softwarelösungen für die tägliche Arbeit braucht, ist die Suche nach der passenden Firma und das exakte Beschreiben des Problems oft aufwändiger, als es einfach schnell selbst zu erledigen. Ich könnte da auf eine sehr leidvolle Liste von Erfahrungen zurückblicken. Am Ende schafft man sich dann halt norgedrungen ein wenig VBA drauf und baut sich ne Access Datenbank. Der Code ist Kraut und Rüben (zumindest am Anfang) ... Keine Frage. Aber dafür macht die Anwendung genau das, was man täglich braucht und nicht das, was der Softwareentwickler denkt, was man brauchen könnte. Eine gewisse Berechtigung haben solche Lösungen, bei allen ersichtlichen Nachteilen, daher schon 😉
Wir haben bei uns auch eine unternehmenskritische Access-Anwendung. Der ursprüngliche Autor wurde in eine andere Abteilung versetzt und möchte sich um seine Altlasten nicht mehr kümmern. Die Nachfolger - und es gab bereits einige - sind mit der Pflege einer Access-Anwendung überfordert. Nun hoffen alle einfach auf das Beste - was auch immer das genau bedeuten mag.
@@rolfspeer5403Ich denk Mal im Quellcode der VBA Anwendung gibt es keine Kommentare. Die Anwendung hat auch keine Dokumentation und es gibt keine Mitschnitte von Anforderungsbeschreibung die man den früheren Entwickler gestellt hat.
No- oder Low-Code-Plattformen sind auch für nichts anderes, als Prototypen zu gebrauchen. Mir fällt zumindest keine große Software ein, die mit einer solchen Plattform entwickelt worden wäre. In der Firma, wo ich meine Ausbildung gemacht hatte, hatten wir 2020 für ein Team und später 2 Teams OutSystems verwendet, um Prototypen zu bauen und auf Basis derer wurde später in C# weiterentwickelt.
Ist es nicht eine ziemliche Geldverschwendung, OutSystems nur für den Prototypenbau zu nutzen und dann mit C# weiterzuentwickeln? Ich mein, die Plattform ist nicht gerade günstig - es sei denn, ihr habt die kostenlose Demo-Plattform / sozusagen die Community Edition im Geschäft benutzt. Wären Clickdummies mit Figma oder so nicht günstiger gewesen - da hätte man sich auch das erstellen von Dummydaten für die UI gespart. Wäre der Ansatz, OS für die UI, die Clientbasierten Funktionen, Rollen-/Rechte-System, Authentifizierung zu nutzen und dann die Dinge, die ihr mit C# geregelt haben wollt als Extension einzubinden nicht einfacher, schneller, günstiger gewesen?
Also ich bin da kein Fan von. Auch wenn es dafür sicher auch Anwendungsfälle gibt. Ich denke aber, dass man Software in vielen Fällen so generisch schreiben kann, dass der Anwender diese noch relativ leicht anpassen kann.
Man kann es ja auch umdrehen. Stell dir vor du bist Entwickler und hast keine Ahnung von Versicherungen. Kommst du auf die Idee den Versicherungsschsden zu bearbeiten? Du hast ja die jki tools die dir helfen.... Nein kämst du nicht. Aber anders herum meinen Personen zu oft dass es eine gute Idee wäre die itv zu umgehen. Dafür lebt auch die It mit Sicherheit und Ausfällen aus
Dein beispiel mit der Power Plattform trifft es ganz gut. Du hast eine Aufgabe, weißt aber mit den Tools nicht umzugehen. Weshalb? Weil dir etwas Wissen und etwas Erfahrung fehlt. Das Ergebnis ist mist. Dein Vergleich aber, ausgebildete Entwickler herzunehmen, die nichts anderes und spezielles wie tieferes machen, hinkt stark. Du vergleichst nämlich jemand mit keiner Ahnung, mit einem Profi. Bei den Lowcode Plattformen geht es darum ohne Programmier-Skills SCHNELLER ans Ziel zu kommen - nicht ohne Wissen einen Programmierer zu ersetzen. Versetzen den Lowcode Anwender auch mit etwas Erfahrung und Wissen - er wird seine gewünschten Ziele sicher gut und schnell erreichen. Er wird auch starke Limitierungen haben, keine Frage. Ohne Wissen und Erfahrung geht nichts, erst recht nicht schnell und einfach.
"Versetzen den Lowcode Anwender auch mit etwas Erfahrung und Wissen" Welche Erfahrung und Wissen wird denn der Lowcode "Anwender" deiner Meinung nach brauchen, um erfolgreich zu sein? "Programmier-Skills" hast du ja ausgeschlossen.
@keinname2378 die Funktionen der lowcode Plattform, wie man sich Sachen selbst Zusammenbau und einen grundlegenden Aufbau von solchen kleinen Tools. Um sich kleine Helfer zu bauen langt das absolut. hier wurde vom einfachen Copy&paste Tool bis zu Daten via Api abholen alles in einem Topf geworfen und kräftig verrührt. Es geht bei lowcode nicht darum etwas zu ersetzen oder Funktionen zu erweitern, sondern die Bedienung am frontend zu automatisieren oder etwas, was man händisch machen muss fixer zu gestalten. Das wars
Es profitiert nicht nur der Plattform Hersteller. Es gibt ja auch noch den Power Plattform Developer, der dadurch einen Job hat. Und ich bin mir sicher, dass auch die Fachabteilung, die die resultierenden Probleme und das Risiko nicht sehen, zumindest teilweise ihren vermeintlichen Erfolg über die IT, als Errungenschaft empfindet und diesen vielleicht sogar verkauft. Man holt also die Beteiligten auf einer persönlichen Ebene ab.
![[Live] : ONE FIGHT NIGHT 26 วันนี้!! “คริสเตียน vs อาลิเบก”](http://i.ytimg.com/vi/UlIiZ3t8nHQ/mqdefault.jpg)
Du möchtest das Video an jemanden weiterleiten, die oder der aber lieber liest? Dann findest Du den passenden Artikel zum Video bei Heise Developer: www.heise.de/blog/Low-Code-Co-Mehr-Schaden-als-Nutzen-10184237.html
ich bin Software-Entwickler (C#) im Rahmen von Microsoft Dynamics CRM.
Ich schreibe regelmässig Plugins in C# und "kämpfe" immer wieder mit den nicht ganz-so-technischen Kollegen, welche Low-code-Plattformen in den Himmel loben.
Der Weg, den wir jetzt gefunden haben, ist der, dass ich mittels C# Bausteine für Low-Code-Plattformen entwickle, welche dann von den Fachabteilungen verwendet werden können.
So können viele Vorteile der Low-Code-Plattform genutzt werden und dennoch habe ich im Hintergrund die Möglichkeit verschiedene technische Einschränkungen/Eigenheiten etc. "sauber" lösen zu können.
Ich glaube das ist ein durchaus praktikabler Ansatz. Aber frage mich schon ob es diesen großen Individualismus in vielen Unternehmensprozessen durch LowCode überhaupt braucht. Also ob man sich langfristig damit nicht erst wieder Aufwände schafft die bei langsamerer Individualisierung durch echte Entwicklung von vornherein vermieden werden könnten. Stichwort Berechtigungsmanagement, Kompatibilität usw.
@@dominik4496 Genau - ich höre bei uns immer wieder das Argument, dass Low-Code halt schneller/günstiger sei.
Allerdings nur kurzfristig - weil eben auf längere Sicht immer wieder die gleichen Themen auftauchen (Stichwort Kompatibilität und Erweiterbarkeit).
Klar muss nicht jede Individualentwicklung bis ins letzte Zeichen konfigurierbar sein - aber ein gesunder Mittelweg zwischen Flexibilität und Stabilität bringt mittel- und langfristig am meisten Nutzen.
Leider kostet dieses Vorgehen im ersten Moment etwas mehr Ressourcen, weshalb wir als Entwickler in vielen Fällen einen schweren Stand haben, dies zu rechtfertigen (sofern die Entscheidungsträger keine Entwickler sind).
Wenn es nachher dann doch noch verändert werden muss, sollte dies am besten noch "gratis" passieren, weil "wir es ja am Anfang nicht richtig" gemacht haben 😞
Da helfen mir Low-Code-Plattformen und die von mir entwickelten Schritte dafür:
Es ist einfacher zu argumentieren, dass ein kleines Plugin in sich geschlossen ist und eben nicht erweitert werden kann, als eine vollständige Applikation.
@@MarkusH87 Dann öffne ich den Editor, und erweitere die LowCode-Anwendung. Wenn immer wieder die gleichen Themen auftauchen, setze ich ein Modul auf Public und kann es in den anderen Applikationen nutzen.
@@RaveKev "Wenn immer wieder die gleichen Themen auftauchen, setze ich ein Modul auf Public und kann es in den anderen Applikationen nutzen."
Das machen 5 deiner Kollegen aber auch. Aber gut, dann hast du nach ein paar Jahren wenigstens ein gutes dutzend Module zur Feiertagesermittlung (International), Feiertagsermittlung (DACH), Feiertagsermittlung (DACH-Ohne-BW) und Feiertagsermittlung (Uwe, bis Q42027, V17 ohne Foo). Da ist bestimmt was passendes dabei. 🙂
@@lupf5689 Wo genau ist da der Unterschied zu anderer Softwareentwicklung? Wenn die Firma ein Problem hat, Dinge zu planen bzw. geordnet zu nutzen wird sie es mit jeder Sprache haben.
Oder soll ich mal schauen, wie viele Nuget, NPM oder andere Bibliotheken es gibt, die sich mit der Feiretags-Thematik befassen?
Danke für das Video. Das Lustige war, dass in der Werbung zwischen deinen Worten für genau so ein LowCode CRM System beworben wurde.
Ich finde es sehr gut, wie du redest, welche Wörter du verwendest und wie du die Themen erklärst.
Eine sehr treffende Zusammenfassung! Ich lasse die Low-Code-Enthusiasten gerne ihre Ansätze ausprobieren - oft zeigt sich bei wachsender Komplexität, dass die Grenzen schnell erreicht sind. Häufig höre ich dann von Projektverantwortlichen, dass die neue Indiv-Entwicklung jetzt sehr kostengünstig umgesetzt werden muss, nachdem der Low-Code-Ansatz gescheitert ist und schon viel Budget verschlungen hat. Es ist interessant zu sehen, wie schwer es manchmal ist, diesen Punkt im Voraus zu vermitteln, auch wenn man es bereits beim ersten Meeting anspricht.
Spannenderweise ist das bei unseren Kunden häufig anders.
Da steht eine Softwarelösung die in HighCode geschrieben wurde und auf einmal bricht die Abteilung oder die Firma, die das System umgesetzt hat weg. Dann steht man da (quasi ein VendorLock). Dann müssen sich Leute nochmal komplett einarbeiten und die Software neu schreiben.
Dass man dann auf LowCode umsteigt ist aufgrund der benötigten Zeit mit HighCode eine nicht zu unterschätzende Möglichkeit.
Man kann Leute, welche bereits Erfahrung in Programmiersprachen haben, sei es auch "nur" JavaScript oder so, sehr schnell darin enablen und an den Projekten arbeiten lassen.
Es ist wie immer. Es kommt darauf an das passende Werkzeug und die passende Person für die Aufgabe auszuwählen. Je besser dies gelingt, desto besser ist das Ergebnis. Verschiedene Konstellationen können da gleichermaßen zum Ziel führen.
Ein schlechter Prozess ist digitalisiert, auch nur ein schlechter digitalisierter Prozess.
Grundsätzlich ist der Low Code Ansatz ok. Aus eigener Erfahrung (ich arbeite inzwischen gut 4 Jahre damit) muss ich sagen, dass die von uns verwendete Plattform von einem Fachbereich selbst unmöglich verwendet werden könnte. Dazu braucht es allen Versprechungen zum trotz erfahrene Programmierer, wie die aus meiner Abteilung. Denn man muss letztlich Grundlagenwissen wie OOP, Datenbankverständnis, Netzwerk, je nach dem auch Speichermanagement, und und und. mitbringen. Halt alles Basics, die ein Programmierer kennen muss, egal welche Art von Sprache er programmiert.
Daher ist die Programmierung eines einfachen Tools zwar meist relativ schnell erledigt. Aber sind erst mal Begehrlichkeiten geweckt und es gibt Erweiterungen oder Spezialisierungen, dann nimmt auch der Zeitaufwand zu, und der Vorteil solcher Plattformen nimmt im Verhältnis ab.
Das Problem wurde schon vor über 50 erkannt und mit Generatoren zu beheben versucht. In den 80er/90ern entstanden extrem fortschrittliche grafische Tools, die verschiedene Abstraktionsebenen nutzen und synchron halten konnten - alles vergebens: Die Schwierigkeiten mit unbestimmten, wechselnden, widersprüchlichen und nicht abgestimmten Fachanforderungen waren nie in den Griff zu kriegen.
(vom Debugging etc gar nicht zu reden).
Alles, was man mit einem Generator hinbekommt kann man auch mittels einer Library bauen. Eine lib ist einfacher zu pflegen, DRY Pattern. Der Traum nach den Generatoren geht ungebremst weiter und es scheitert fast immer.
Ich bin auf der Verkauf-den-Krams-Seite und mein Sourcerer hat mich hierher geschickt. Schon länger nicht mehr so klare Ansagen gehört. Vielen Dank! :)
Habe vor einer Weile mit Apache Camel Karavan arbeiten müssen. Das war gut um den Kunden ein Projekt aufzuschwatzen, wo sie ganz einfach selber dran arbeiten können, ohne viel von Camel zu wissen. Oftmals will man dann aber doch mehr umsetzen und das war mit der Low Code Lösung einfach lästig/nervig, sodass man argumentiert hat "Wenn es ein reines Camel Projekt wäre, würde alles viel schneller gehen". Also letztlich ein Marketing Tool.
Was für wahre Worte, mein Lieber, es geht nur mit einem Miteinander. Ein gemeinsames Ziel zu erreichen. Zusammen, das beste Produkt erschaffen, was unser Kunde braucht. Was uns legitimiert das zu tun, was wir tun.
Naja kann man inzwischen sicher auch als Person im Einkauf etc. einfach ein LLM machen lassen.
Einfach sagen ich brauche XY, schreibe mir einen Code und sage mir was ich machen muss, damit dieser läuft und dann hat sich das, bis der erste Bug auftritt.
Das wird noch ein Spaß werden, sage ich euch!
Das möchte ich sehen, dass ein Nicht-Entwickler ausschließlich mit Hilfe von ChatGPT eine lauffähige Anwendung abseits einer trivialen Web-App baut. Ohne ein Verständnis davon wie Software funktioniert ist man gar nicht in der Lage Promts so spezifisch zu formulieren dass die Software das macht was man möchte.
Ja, LLM soll gut drinn sein Code zu generieren der richtig aussieht aber subtil irgendwo falsch ist.
Hab selbst einige Jahre in einem Unternehmen gearbeitet, welches die Programmierung eines neuen IT Projektes an einen Dienstleister gegeben hat, der auf Low-Code gesetzt hat.
Aus meiner Erfahrung sind die Platformen für große Projekte komplex, dass man trotzdem "Programmierer" braucht, benötigte nicht Standardfunktionaliäten werden mit aufwändigen Workarounds umgesetzt, Unternehmen binden sich an Plattformunternehmen und deren Überleben, aus Softwaretestsicht sind die Umsetzungen graußam.
Daher für kleine Unternehmen die eine kleine Softwarelösung brauchen, kann Sinn machen, für alles andere lieber nicht.
Low-Code Plattformen sind m.E. auch nur als Framework zu verstehen. Sie nehmen einem Arbeit ab, genauso muss man aber man aber auch verstehen, wo die Limitierungen liegen.
Wir nutzen für unsere Kundenprojekte Pro-Code & Low-Code Lösungen. Je nach Anforderung bzw. Anwendungsbereich entscheiden wir uns für die Plattform die am meisten Sinn macht.
ich habe vor einigen monaten eine facharbeit zum thema low-code/no-code bei sap build apps geschrieben, wo analysiert wurde, ob nicht-entwickler nach einer vorher durchgeführten schulung damit eigenständig etwas entwickeln können...das ergebnis war: keine chance ohne programmierkenntnisse...es ist für fachanwender viel zu komplex...stichwort: API-anbindung
Die Zielgruppe für Low-Code sind dann Semi-Programmierer, also Fachanwender die ihren Workflow bereits mit selbst geschriebenen Skripten unterstützen.
Diese Erkenntniss habe ich selbst bei mir erlebt. Nun lerne ich wirklich die Basics und will erstmal da rein kommen bevor ich mir so was überlege. Das Stichwort mit API Anbindung ist gut
Auf den Punkt! Für Prototyping, damit die Fachabteilung ihre eigenen Prozesse definieren kann sehr gut geeignet. Für mehr aber auch nicht. Ein Marketing-Produkt, genau wie die Meinung, dass KI jetzt alles schneller, besser und einfacher löst. Leider fallen darauf viele Entscheider herein. Problem sind hier die Berater und die HR Leute, egal ob im Personalbüro oder die Projektvermittler. Leider haben diese vom fachlichen keine Ahnung und geben sich auch wenig Mühe. Mir kommt es manchmal so vor, als würden die als Verkäufer in einem Autohaus arbeiten, haben aber nicht mal das Prospekt gelesen. IT ist auch Fachwissen, deren Grundkenntnisse in den Fachbereich gehören, so wie Entwickler Kenntnisse aus dem Fachbereich haben müssen.
Ich hab in diesem Video gelernt das ich künftig immer zuerst zu netten Kollegin gehe statt zum grummeligen Kollegen
Danke!
Tja, ich weiß nicht so genau. Ich bin selber für die öffentliche Verwaltung tätig. Hier steht man immer wieder vor eher leichten und immer sehr ähnlichen fachlichen Prozessen: Ein Antrag wird gestellt, irgendwer muss seinen Stempel drunter machen, jemand muss eine Entscheidung treffen, jemand muss ein Datum ergänzen, irgendetwas muss irgendwo hin archiviert werden, am Ende ist der Antrag durch und geht zurück an den Antragsteller, vielleicht wird zwischendurch mal ein Nachbarsystem angefragt.
Und zumindest GUI-seitig sehen die entsprechend alle sehr ähnlich aus und auch die Datentöpfe hinten dran sind jetzt nicht unbedingt speziell. Da fragt man sich ja: Warum muss für jeden dieser Fachanwendungen wieder eine neue Angular Anwendung gebaut werden, die auch entsprechende Wartung braucht? Warum kann ich mir die passenden Masken nicht einfach entsprechend zusammenklicken oder gar aus vorliegender BPMN generieren lassen?
Und genau das scheinen Low-Code Plattformen ja anzubieten, klingt also nicht unplausibel. Andererseits hört man kaum Erfolgsgeschichten aus dem Bereich und Vendor Lock In möchte man auch nicht so gern. Schwierig zu sagen, was da jetzt richtig ist...
Ich bin ein riesen Fan deiner/eurer Videos und teile sie regelmäßig in unserer Firma.
Allerdings lässt mich das Video einigermaßen sprachlos zurück - gerade in Hinsicht auf die letzten Worte zum den "Wir-gegen-die"-Ansatz.
Werde es trotzdem versuchen einiges dazu zu schreiben.
Ich bin seit 2008 Java-Entwickler aber seit 4 Jahren als Low-Code-Entwickler (OutSystems) unterwegs.
Eins vorweg: auch wir sehen den Citizen-Developer-Ansatz noch etwas kritisch wegen der von dir beschriebenen Probleme.
Es gibt natürlich unterschiede der verschiedenen Plattformen wie PowerPlattform, Appian, Mendix oder OutSystems.
Da ich OutSystems-Entwickler bin (ja, man kann Entwickler darin sein - es ist ja schließlich keine NO-Code-Plattform), werde ich größtenteils das Thema aus dieser Sicht beschreiben. Und ohne anderen zu nahe treten zu wollen, bin ich wirklich froh, bei OS gelandet zu sein, statt einer der anderen Plattformen.
Denn:
Wir sind eine Consulting-Firma deren größter Teil die Entwicklungsdienstleistung mit C# oder OutSystems ist. Die dem LowCode häufig vorgeworfenen MickeyMaus-Applikationen mit ein paar Eingabemasken sieht man zwar auch, aber die Software an der wir arbeiten sind große, firmenkritische Anwendungen, die teilweise auch der Dreh-und-Angelpunkt des Geschäftes werden.
Mit einer gehosteten LowCode-Plattform bleiben für Kunden die Wartungsarbeiten erspart, und man kann sich auf die Entwicklung stürzen, welche wirklich nur einen Bruchteil der Zeit benötigt.
Wenn andere Entwickler in ein Projekt kommen, ist die Einarbeitungszeit um einiges schneller, da man den Code durch die optische Entwicklung und standardisierte "Knoten" auf ein paar Blicke verstehen und sich auskennen kann.
Der Vendor-Lock ist natürlich teilweise vorhanden, wird aber bei OS dadurch aufgeweicht, dass man sich den generierten Quellcode (JavaScript sowie .Net-Code) beim Kündigen des Vertrages bereitstellen lassen kann. Man könnte also auch danach noch etwas weiter an der Software entwickeln (wie sinnvoll das ist, ist dahingestellt, da der Code zwar menschenlesbar ist, aber nicht suuuuuuuper intuitiv).
Die Punkte, die hier vorgeworfen werden sind, wie wenn man Affinity Designer oder Adobe Illustrator vorwerfen würde, dass sie mies sind, da jetzt jeder Abteilungsleiter Logos und Grafiken erstellen könnte.
Ja, kann man ABER das ist nicht unbedingt das Ziel.
Nicht umsonst ist hat OutSystems einen Rahmenvertrag für die Öffentliche Hand erhalten, wodurch es Kommunen der gesamten Öffentlichen Verwaltung einfacher gemacht wird, Projekte damit zu starten.
Das ganze klingt jetzt natürlich nach Werbung - soll es aber gar nicht sein. Ich für meinen Teil bin einfach mega überzeugt davon WIE und WOMIT ich tagtäglich arbeite und WAS ich für den Kunden abliefere.
Wenn ihr möchtet, kann ich euch gerne mal zeigen, wie ich entwickle und ggf. eine kleine Einführung in OutSystems geben,.
Nach den ganzen Jahren Java, C# und Angular-Entwicklung fühlt es sich so an, als sei ich angekommen.
Wir haben von OutSystems auf Mendix gewechselt. Leider. Ich empfand OutSystems als einfacher und intuitiver zu bedienen. Aber sogar dort hätte ich Mühe, dieses den Fachbereichen vorzusetzen. Auch wenn es einfacher ist, denke ich, die Fachbereiche sollten sich um ihr Ding kümmern, die IT und gesonderte Entwicklungsabteilungen machen die Applikationen. Schon um eine gewisse Architektur entstehen zu lassen, die letztlich auch wieder Qualität und Aufwand verbessert.
@@reneberger6340 Das ist komplett richtig! Bin auch der Meinung, dass es Entwickler-KnowHow braucht, um langlebige und erweiterbare Software zu schreiben.
Wir haben auch einmal getestet, völlig Entwicklungs-Fremde Personen als Quereinsteiger in LowCode zu enablen, was in 75% der Fälle auch gut bis sehr gut lief.
"Wenn andere Entwickler dazu kommen und...." halte ich für ein ziemliches Märchen. Es mag stimmen stimmen solange die Anwendung extrem klein ist. Wenn die Anwendung aber etwas komplexe wird und unzählige Knoten besitze und nicht nur aus einem Prozess sondern 30 dann kippt das ganze.
Code ist einfacher zu bearbeiten und zu lesen als sich durch durch die unzählige Quadrate zu scrollen und spätestens beim dritten Bildschirm scrollen die Orientierung verloren zu haben.
@@dd1982bb "beim dritten Bildschirm scrollen die Orientierung verloren zu haben".
Auch bei Low-Code gelten Clean Code vorgaben, wie klein gehaltene, dafür sprechend benannte Actions/Methoden.
"Wir sind eine Consulting-Firma..." Ab spätestens da weiß man, dass da nur noch Unsinn kommen kann.
ich fühl es. Habe eine App nach Bausatzsystem versucht und mein Problem war abseits des vorgegebenen Pfades. Danke, dass ich doch nicht so doof bin ;) Nun lerne ich Java um flexibel zu sein. Somit hatte der Weg seinen Sinn :)
tja. Das Ergebnis suboptimaler Kommunikation zwischen Fachabteilung und IT-Abteilung bzw. Entwicklung kann man täglich beobachten. Die eine Seite weiß nicht, was die andere Seite braucht - und die andere Seite weiß nicht, was die eine Seite aus der Technik herausholen kann - geschweige denn, für welche Probleme sich eine technische Lösung lohnt, und an welchen Stellen eine technische Lösung Abläufe eher verkompliziert oder gar verunmöglicht, wenn nicht alle Eventualitäten des Alltags mitbedacht werden. Also wird einfach geraten, ohne nähere Kenntnis der Materie die Initiative ergriffen, etc. Eigentlich sehr seltsam. 🙂 Aber was man auch beobachten kann: viele sind der Meinung, alles nach bestem Wissen und Gewissen richtig zu machen, während die eine über die andere und die andere über die eine Seite häufig schimpft. 😀 Früher gab es mal so Ausbildungen, in denen man gelernt hat, die Sprache der Kunden und die Sprache der Entwickler zu sprechen und eine Art Schnittstelle zwischen beiden zu bilden. Leider werden die vielerorts offenbar stark unterbewertet.
Für größere oder komplexere Projekte ist lowcode denke ich auch langfristig nichts. Aber für citizen developer, die sich kleinere Sachen basteln, ok, da ist es doch schön, wenn es klappt. Und wenn es nicht klappt, dann wird es auch nicht mehr in den Himmel gelobt werden.
Ich mag den Vergleich mit dem Kartenset, mit dem man Sätze legen kann. Das trifft den Nagel auf den Kopf.
Wir gegen die... oh man, wie oft ich das schon in Projekten erlebt habe. Am Ende stehen dann alle irgendwie als Verlierer da, und mit dem Erzeugnis (der Software) will keiner mehr so richtig was zu tun haben - sehr sehr traurig.
Zum Thema Low-Code/No-Code: In Bezug auf generische Entwicklungsplatformen würde ich mich deiner Meinung anschliessen, die Sinnhaftigkeit solcher Platformen darf man hier sicher hinterfragen.
An anderer Stelle sehe ich aber durchaus eine Berechtigung für Low-Code/No-Code-Ansätze, und zwar dort, wo ich Anwendern explizit eine Anpassbarkeit, aber eben im auch nur im sehr spezifischen Rahmen einräumen will. Low-Code/No-Code also als spezielle Form bzw Erweiterung einer Produkt-Konfiguration.
Die Ansätze, die man heute "Low-Code/No-Code" nennt, gab es schon immer. Wenn ich mich recht erinnere, wurden die früher als "Rapid Prototyping" bezeichnet.
Diese Ansätze haben m.E. durchaus ihre Berechtigung und ihren Nutzen. Sie können z.B. mit relativ geringem Aufwand zum initialen "Ausprobieren" von neuen Anwendungs-Ideen dienen, die sonst aufgrund der normalen IT-Entwicklungs-Prozesse niemals angegangen werden würden. Und wenn man dann erstmal was zum "Vorzeigen" hat und seine "Chefs" vom Nutzen überzeugen kann, dann wird ggf. auch ein "richtiges" Entwicklungs-Projekt aufgesetzt.
Es ist aber auch hier wie mit allen Sachen im Leben - "Hirn einschalten" und nicht allen flotten Marketing-Versprechen der Hersteller blindlings glauben. 🙂
Im Grunde kann man das tatsächlich mit Rapid Prototyping vergleichen, auch wenn heute die Apps einen produktiveren Ansatz haben. Als mein Chef das damals hörte - kein ITler - war er Feuer und Flamme und meinte, jetzt braucht man ja nicht mehr viel machen. Schon gar nicht dokumentieren oder so.. uff..
Das soll auch unser Ansatz werden, also Low-Code als Prototyping Tool nutzen, um Gelder zu sammeln um große, komplexe Software bauen zu können.
Wenn man auch bedenkt, wie viele Leute noch Prozesse mit Excel abbilden, dann wollen wir auch diese Leute zu solchen Plattformen bringen, um dort Gemeinsamkeiten herauszuarbeiten oder schneller einfache kleine Ideen umzusetzen.
Wir stehen aber noch am Anfang des Prozesses bei der Suche nach der richtigen Plattform
Ich habe mich intensive mit Low-Code beschäftigt, ich kann diese Aussagen aus diesen Video nur bestätigen. Wenn ich mit einem Vendor mich einlasse, bin ich gefangen. Stoße ich auf Anforderungen, die nicht mit dem Low-Code Produkt umgesetzt werden können (also im Low-Code Produkt berücksichtigt wurde), bin ich gefangen. Also bitte vorher das Low-Code Produkt genau untersuchen, das bedeutet aber wieder Aufwand, der nicht unerheblich sein kann. Also vorsichtig sein.
Einige LowCode-Plattformen bieten es auch an, eigene Extensions per JavaScript (für die Clientseitigen Dinge) oder beispielsweise .Net (für die Serverseite) zu schreiben. Auch Anbindungen an andere Systeme sind so umsetzbar.
Versicherung?? Das macht der Bernd, läuft 😂
Spass bei Seite, low-no-code habe ich viele +/- mitgemacht in den letzten 30 Jahren. Ich finds super, um mit dem user ins Gespräch zu kommen, statt zB Bilderchen malen. Produktiv hab ich da nix gesehen.
sehr gut erklärt, guter vergleich mit den sprachkarten. danke
Top erklärt
Ich arbeite sehr gerne mit nodeRed aber der JavaScript Block ist mein bester Freund. Man könnte aber vieles vermutlich ohne aber dafür minimal komplexer lösen
Ich musste sehr grinsen beim Anhören dieses Videos. Es gibt halt auch viele kleine Firmen, die vergeblich nach dem netten oder weniger netten Mitarbeiter der IT Abteilung suchen, weil's nämlich überhaupt keine IT Abteilung gibt. Wenn man dann kleinere Softwarelösungen für die tägliche Arbeit braucht, ist die Suche nach der passenden Firma und das exakte Beschreiben des Problems oft aufwändiger, als es einfach schnell selbst zu erledigen. Ich könnte da auf eine sehr leidvolle Liste von Erfahrungen zurückblicken. Am Ende schafft man sich dann halt norgedrungen ein wenig VBA drauf und baut sich ne Access Datenbank. Der Code ist Kraut und Rüben (zumindest am Anfang) ... Keine Frage. Aber dafür macht die Anwendung genau das, was man täglich braucht und nicht das, was der Softwareentwickler denkt, was man brauchen könnte. Eine gewisse Berechtigung haben solche Lösungen, bei allen ersichtlichen Nachteilen, daher schon 😉
Wir haben bei uns auch eine unternehmenskritische Access-Anwendung. Der ursprüngliche Autor wurde in eine andere Abteilung versetzt und möchte sich um seine Altlasten nicht mehr kümmern. Die Nachfolger - und es gab bereits einige - sind mit der Pflege einer Access-Anwendung überfordert. Nun hoffen alle einfach auf das Beste - was auch immer das genau bedeuten mag.
@@rolfspeer5403Ich denk Mal im Quellcode der VBA Anwendung gibt es keine Kommentare. Die Anwendung hat auch keine Dokumentation und es gibt keine Mitschnitte von Anforderungsbeschreibung die man den früheren Entwickler gestellt hat.
No- oder Low-Code-Plattformen sind auch für nichts anderes, als Prototypen zu gebrauchen. Mir fällt zumindest keine große Software ein, die mit einer solchen Plattform entwickelt worden wäre. In der Firma, wo ich meine Ausbildung gemacht hatte, hatten wir 2020 für ein Team und später 2 Teams OutSystems verwendet, um Prototypen zu bauen und auf Basis derer wurde später in C# weiterentwickelt.
Ist es nicht eine ziemliche Geldverschwendung, OutSystems nur für den Prototypenbau zu nutzen und dann mit C# weiterzuentwickeln? Ich mein, die Plattform ist nicht gerade günstig - es sei denn, ihr habt die kostenlose Demo-Plattform / sozusagen die Community Edition im Geschäft benutzt.
Wären Clickdummies mit Figma oder so nicht günstiger gewesen - da hätte man sich auch das erstellen von Dummydaten für die UI gespart.
Wäre der Ansatz, OS für die UI, die Clientbasierten Funktionen, Rollen-/Rechte-System, Authentifizierung zu nutzen und dann die Dinge, die ihr mit C# geregelt haben wollt als Extension einzubinden nicht einfacher, schneller, günstiger gewesen?
Spaghetti-Code in normalem Code: Ärgerlich
Spaghetti-Code in No-Code: Katastrophal
Also ich bin da kein Fan von. Auch wenn es dafür sicher auch Anwendungsfälle gibt.
Ich denke aber, dass man Software in vielen Fällen so generisch schreiben kann, dass der Anwender diese noch relativ leicht anpassen kann.
Man kann es ja auch umdrehen. Stell dir vor du bist Entwickler und hast keine Ahnung von Versicherungen. Kommst du auf die Idee den Versicherungsschsden zu bearbeiten? Du hast ja die jki tools die dir helfen....
Nein kämst du nicht. Aber anders herum meinen Personen zu oft dass es eine gute Idee wäre die itv zu umgehen.
Dafür lebt auch die It mit Sicherheit und Ausfällen aus
Sollen sie Lego verkaufen. Selbst IKEA vermittelt Helfer für den Zusammenbau.
Dein beispiel mit der Power Plattform trifft es ganz gut. Du hast eine Aufgabe, weißt aber mit den Tools nicht umzugehen. Weshalb? Weil dir etwas Wissen und etwas Erfahrung fehlt. Das Ergebnis ist mist.
Dein Vergleich aber, ausgebildete Entwickler herzunehmen, die nichts anderes und spezielles wie tieferes machen, hinkt stark. Du vergleichst nämlich jemand mit keiner Ahnung, mit einem Profi. Bei den Lowcode Plattformen geht es darum ohne Programmier-Skills SCHNELLER ans Ziel zu kommen - nicht ohne Wissen einen Programmierer zu ersetzen.
Versetzen den Lowcode Anwender auch mit etwas Erfahrung und Wissen - er wird seine gewünschten Ziele sicher gut und schnell erreichen. Er wird auch starke Limitierungen haben, keine Frage. Ohne Wissen und Erfahrung geht nichts, erst recht nicht schnell und einfach.
"Versetzen den Lowcode Anwender auch mit etwas Erfahrung und Wissen"
Welche Erfahrung und Wissen wird denn der Lowcode "Anwender" deiner Meinung nach brauchen, um erfolgreich zu sein? "Programmier-Skills" hast du ja ausgeschlossen.
@keinname2378 die Funktionen der lowcode Plattform, wie man sich Sachen selbst Zusammenbau und einen grundlegenden Aufbau von solchen kleinen Tools. Um sich kleine Helfer zu bauen langt das absolut. hier wurde vom einfachen Copy&paste Tool bis zu Daten via Api abholen alles in einem Topf geworfen und kräftig verrührt. Es geht bei lowcode nicht darum etwas zu ersetzen oder Funktionen zu erweitern, sondern die Bedienung am frontend zu automatisieren oder etwas, was man händisch machen muss fixer zu gestalten. Das wars
Irgendwann in nicht allzu ferner Zukunft wird KI bessere Programme schreiben als der Mensch.
Echt jetzt?
Es profitiert nicht nur der Plattform Hersteller.
Es gibt ja auch noch den Power Plattform Developer, der dadurch einen Job hat.
Und ich bin mir sicher, dass auch die Fachabteilung, die die resultierenden Probleme und das Risiko nicht sehen, zumindest teilweise ihren vermeintlichen Erfolg über die IT, als Errungenschaft empfindet und diesen vielleicht sogar verkauft.
Man holt also die Beteiligten auf einer persönlichen Ebene ab.
No Code dürfte für niemanden kritisch sein, ausser für die No Brainer der IT-Abteilung.
man kann es eigtl. auf eine zentrale Aussage herunterbrechen:
No code macht einfache Dinge einfacher und die schwersten 10% unmöglich
Wer von Low Code spricht, darf von Excel nicht schweigen! 😉
Low code ist Blödsinn.