Ist Low Code der richtige Weg?

R

ralli

Guest
Angeblich verspricht Low-Code eine große Zeitersparnis, da Entwickler weniger Code schreiben müssen – das wäre ja auch eine vermeintlich mögliche Kostenreduzierung. Werden die Kosten dann nicht umgelagert und der Kunde blutet für die fehlende Nachhaltigkeit?

Ist deshalb agile Softwareentwicklung unvermeidbar? Weil Zeit Geld ist?

Mangelnde Geduld führt dazu, das nicht auf die Fertigstellung des Produktes gewartet werden könne, weil die Fachbereiche das Ergebnis am liebsten bereits gestern sehen und vermarkten möchten....

Ist das eine gute Entwicklung oder bedeutet low code auch low quality?

Gibt es zukünftig nur noch unreife Software, die erst beim Kunden reift?

Das möchte ich hier mal zur Diskussion stellen. Was für eine Meinung habt Ihr zu diesem Thema? Seid Ihr in Eurem beruflichen Umfeld schon darauf aufmerksam geworden? Das würde mich mal interessieren.
 
Äh, ich bin mir jetzt nicht 100%ig sicher was du meinst, falls damit grafische Bausteinprogrammierung gemeint ist:
Kenn sowas nur von Access, VBA ist ohnehin sehr langsam, wenn ich dies nun noch über die Grafiktools "programmiere", baue ich einen Overhead (unnützen Code), in eine Sprache mit großem Overhead (VBA) innerhalb eines weiteren Overheads (Access). Wenn man Bausteine verwendet ist es nunmal in der Regel so, dass diese Eventualitäten abdecken, welche ich nicht brauche = Overhead.

Sehe hier keinen großen Unterschied zur normalen Webentwicklung bzw. Frameworknutzung
 
Finde sowas immer ganz witzig:

Nun mal am Beispiel einer interpretierten Sprache mit Overhead:
python2:

Code:
x = "Hello "
y = "World"
z = x + y
print z
(ist ungetestet, ich kann kein python)

Der Interpreter muss den Datentyp von x und y erkennen -> gewisser Aufwand
Uebergabe des Datentyps an z und x + y uebertragen, vermutlich noch Speicheranforderung auf z.
Anschließende Ausgabe und vermutlich einiges an Exception Handling. Ich sehe hier relativ viel Overhead in wenig Code.

Code:
#include <stdlib.h>
#include <unistd.h>

int
main()
{
        char x[] = "Hallo ";
        char y[] = "Welt\n";

        char *z;
        unsigned short size, size2;
        for (size = 0; x[size]; size++);
        for (size2 = 0; y[size2]; size2++);

        if ((z = malloc(size + size2)) == NULL)
            return EXIT_FAILURE;

        unsigned short i;
        for (i = 0; i != size; i++)
            z[i] = x[i];

        for (i = 0; i != size2; i++)
            z[i + size] = y[i];

        (void) write(STDOUT_FILENO, z, (size + size2));
        free(z);

        return EXIT_SUCCESS;
}
Hier der gleiche Unsinn in C, kein Exception Handling und keine automatische Typerkennung. Das Programm macht ganz genau, worum ich es bitte: Effizienz.

Nun die Bildprogrammierbastelei:
Ich vermute es wird zB einen Baustein für Stringkombinationen und Ausgaben geben, dieser könnte nun speziell in der Anwendung sein und somit weniger Overhead wie Python haben, kann jedoch dann nur Strings oder es gibt einen leichter anzuwendenden Baustein der beliebig viele Eingaben annimmt und ausgibt. Dieser braucht dann etliche verbaute Sonderfunktionen um zB. die Masse der Variablen zu zählen und sie dynamisch je nach Größe auszugeben, heißt: Viel mehr Code und somit noch mehr Overhead!
 
Zuletzt bearbeitet:
Ich bitte meine unqualifizierte Sichtweise zu entschuldigen, aber wenn ich verkehrt denke, werde ich schon korrigiert. Ist es denn so, das Overhead heute noch eine große Rolle spielt im Zeitalter des billigen Arbeisspeicher? Wenn ich sehe, was @mogbo gepostet hat, dann geht es ja augenscheilich um Effizienz, also auch um eine Leistungssteigerung. Und da ist eine automatische Typerkennung zwar komfortabel, aber mindert dann doch wieder die Leistung. Allerdings gibt es ja heute nicht nur billiges RAM, sondern die Prozessoren sind ja auch um ein vielfache leistungsfähiger geworden. Früher war für zeitkritische Anwendungen assembler ein Muß, ich denke da an dBase, was ja in Assembler erstellt wurde. Spielt das bei der Leistungsexplosion heute denn noch wirklich alles eine Rolle? Ich frage, weil ich mit der technischen Entwicklung nicht mithalten kann und deshalb um Aufklärung bitte, damit ich nicht dumm sterbe.;)
 
Den Artikel hab ich gelesen. Meiner Erfahrun gnach trifft der Absatz auf der letzen Seite es:

An dieser Stelle sei auf das meistens geltende Paretoprinzip in der Softwareentwicklung hingewiesen: Low-Code-Plattformen erreichen 80 Prozent der Ergebnisse eines Softwareprojekts, für die verbleibenden 20 Prozent sind aber leider 80 Prozent des Aufwands zu leisten. Die zeitintensiven komplexesten Teile einer Software lassen sich auf absehbare Zeit nicht generieren.

Alle Tools stellen ein Framework zu Verfügung. Nur: Es gibt immer Ecken und Kanten die in der Theorie so nicht auftauchen und in der Praxis Probleme bereiten.
 
Ich habe den Artikel auf Heise gelesen und verstehe ihn immer noch nicht.
90% lesen sich wie das Werben für 90iger RAD Produkte an Java Programmierer und die sind bekanntlich recht langsam/umständlich im Kopf. Was man will ist Wiederverwendbarkeit leider steigert jede Verallgemeinung die Komplexität des Codes bis man wieder alles neumacht.
Und noch ein Wort zu Assembler, ich habe davon gehört aber niemand hat das bei uns jemals eingesetzt und zeitkritisch ist da vieles.
IMO findet das nur Verwendung für Entwickler bei Third Party Bibliotheken oder wenn man spez. Prozessorfeatures nutzen will, also Nische der NIsche.
 
Spielt das bei der Leistungsexplosion heute denn noch wirklich alles eine Rolle?
Jaein, kommt auf die Anwendung an:
  • ist mir das x-fache an Entwicklungszeit die x-fache Geschwindigkeit wert?
  • hat mein Gerät die Leistung und den Speicher mit Sprache y zu arbeiten?
  • gibt es für diese Architektur überhaupt eine Sprachauswahl?
  • wie oft verwende ich meine Anwendung?
  • wer muss mit der Software weiterarbeiten?
  • wie stabil muss die Anwendung sein und wann/wie wird diese gestartet?
 
Das große Thema "generierter Code" kommt schon seit den 1960ern Jahren so alle 5 bis 10 Jahre wieder mal hoch und soll jeweils durch gerade aktuelle technische Neuerungen den großen Durchbruch erfahren. Bisher hat das nicht geklappt, da es zwar einfach ist vorhandene Bausteine zusammenzuklicken, aber extrem schwer tatsächlich Code aus einer (pseudo)formalen Beschreibung zu generieren. Alleine Bausteine zusammenklicken reicht in den allermeisten Fällen aber nicht aus, wie man vor einigen Jahren z.B. durch das Scheitern von BPMN gelernt hat. Außerdem muss jemand die Bausteine entwickeln, was wiederum je nach Komplexität sehr aufwändig sein kann... Unter dem Strich war die Idee vom "generierten Code" damit immer gut, aber in letzter Konsequenz nicht praxistauglich bzw. letztendlich doch wieder so teuer, dass man auch gleich klassisch entwickeln konnte. Und ich sehe nicht, dass sich das geändert hat.

Allerdings gibt es ja heute nicht nur billiges RAM, sondern die Prozessoren sind ja auch um ein vielfache leistungsfähiger geworden.
Allerdings laufen wir gerade bei Prozessoren immer mehr in die Grenzen der Physik. Einzelne Kerne sind schon seit Jahren nicht mehr nennenswert schneller geworden, weder durch IPC- noch durch Taktsteigerung. Will man die erhöhte Leistung moderner Prozessoren abrufen, muss man seinen Workload daher per Threads auf mehrere Kerne verteilen. Und nebenläufig zu programmieren ist ganz allgemein gesagt erst einmal sehr, sehr anspruchsvoll. Gerade, wenn man das Problem nicht in getrennte Datensätze für jeden Thread zerlegt bekommt.
Dazu kommt, dass auch die Anzahl der Kerne und damit der Grad der Parallelisierung nicht ewig wachsen wird. Wir nähern uns nun der 7nm Produktion, mit EUV-Lithographie kommt man vielleicht noch bis 3nm runter, kratzt dann aber auch schon im Bereich der Quanteneffekte... Wenn kein großer technischer Durchbruch kommt, werden wir uns damit abfinden müssen, dass Computer in einigen Jahren nicht mehr nenneswert schneller werden. Und dann bleiben nur noch effizientere Software oder mehr Kisten nebeneinander, mit entsprechendem Einsatz von Platz und Energie.

nd noch ein Wort zu Assembler, ich habe davon gehört aber niemand hat das bei uns jemals eingesetzt und zeitkritisch ist da vieles.
Es ist zwar nicht unmöglich, aber doch sehr schwer nennenswert schlauer als ein moderner Compiler zu sein. Etwas in Assembler händisch zu optimieren lohnt sich wenn überhaupt nur noch für kompakte, gute überschaubare Algorithmen. Und selbst da muss man abwägen.
 
Jaein, kommt auf die Anwendung an:
  • ist mir das x-fache an Entwicklungszeit die x-fache Geschwindigkeit wert?
  • hat mein Gerät die Leistung und den Speicher mit Sprache y zu arbeiten?
  • gibt es für diese Architektur überhaupt eine Sprachauswahl?
  • wie oft verwende ich meine Anwendung?
  • wer muss mit der Software weiterarbeiten?
  • wie stabil muss die Anwendung sein und wann/wie wird diese gestartet?
Womit wir dann beim Pflichtenheft wären, worin die Anforderungen präzisiert und konkret beschrieben werden.
 
Hier der gleiche Unsinn in C, kein Exception Handling und keine automatische Typerkennung. Das Programm macht ganz genau, worum ich es bitte: Effizienz.
Dafür hat die C-Lösung auch viel mehr Möglichkeiten Fehler einzubauen.
Klar. Wenn man "zu Fuß" programmiert hat man viel mehr Einflussmöglichkeiten was auch u.a. der Effizienz zu Gute kommt.
Dafür ist die Python-Lösung übersichtlich und robust.

Man muss dann halt abwägen, was für den konkreten Fall wichtig ist. Und es lässt sich ja auch beides kombinieren.
Das sieht man ja an Python-Paketen wie NumPy. Die Schnittstelle ist das relativ übersichtliche und einfache Python. Die Berechnungen finden aber in effizienten C-Code statt.
 
Unter dem Strich war die Idee vom "generierten Code" damit immer gut, aber in letzter Konsequenz nicht praxistauglich bzw. letztendlich doch wieder so teuer, dass man auch gleich klassisch entwickeln konnte. Und ich sehe nicht, dass sich das geändert hat.
Bei solchen Sachen ist halt auch immer die Frage, wie man es einsetzt. Wenn man versucht damit alles zu erschlagen wirds eher schwierig. Für Teilaspekte kann es aber durchaus funktionieren. Sowas wie GUIs zusammenklicken oder whatever.

Und nebenläufig zu programmieren ist ganz allgemein gesagt erst einmal sehr, sehr anspruchsvoll.
Kommt drauf an. Funktionale Sprachen sind ja u.a. deshalb wieder so beliebt, weil man Sachen wie Nebenläufigkeit fast geschenkt dazu bekommt.

Gerade, wenn man das Problem nicht in getrennte Datensätze für jeden Thread zerlegt bekommt.
Klar gibt es Sachen, die sich schwer parallelisieren lassen.
In der Praxis ist es aber so, dass viel Potential auch ungenutzt ist. Die Softwareentwicklung hinkt da doch teilweise sehr hinter den Möglichkeiten hinterher.

So schnelllebig wie sich die Branche gibt, ist sie nämlich nicht.
Merkt man ja auch immer wieder an solchen Sachen, wo lediglich alter Wein in neuen Schläuchen verkauft wird.

Und dann bleiben nur noch effizientere Software
Da ist sicher noch Luft nach oben. Gerade in der heutigen Zeit, wo Software auch gern mal zusammengepfuscht wird. Sei es wegen Zeitdruck oder weils halt schlicht irgendwie funktioniert.
 
Low Code -> Low Brain.
Der Sinn dahinter ist ja nicht weniger Code (Gesamtcode bleibt gleich), sondern dass weniger qualifizierten Programmierern einfach mehr zugeschoben werden kann.

Rob
 
Low Code -> Low Brain.
:-)

Apropos. Da fällt mir ein, dass ich die Bezeichnung Low Code ohnehin etwas gewöhnungsbedürftig finde.

Ich bin jetzt kein guter Kenner der englischen Sprache, aber für mich hört sich das komisch an und ich würde eher zur Bezeichnung Less Code tendieren.

Low würde ich eher mit niedrig übersetzen. In in Bezug auf niedriger Füllstand in einem Behälter/Tank. Oder fast leerer Akku usw. Von mir aus auch niedrige Temperatur.
Also wo es einen Bezugspunkt (voller Füllstand oder was auch immer) gibt.

Über Umwegen könnte man es vielleicht so interpretieren, dass Low Code bedeutet das eben die Menge an Hand geschriebenen Code in Bezugs aufs Gesamtprojekt relativ niedrig (also low) ist.
Dann würde es wieder Sinn ergeben.

Konnte irgendwer meinen Gedanken folgen oder rede ich nur Bullshit? :-)

Genauso finde ich ja auch agile Softwareentwicklung ein unglücklichen Begriff. Das klingt so, als ob man ohne groß zu planen einfach drauf los programmiert, was ja auch eigentlich nicht stimmt (gut; die Praxis sieht dann wieder anders aus *g*).

Der Sinn dahinter ist ja nicht weniger Code (Gesamtcode bleibt gleich), sondern dass weniger qualifizierten Programmierern einfach mehr zugeschoben werden kann.
Ich denke mal, der Sinn dahinter ist weniger _handgeschriebener_ Code.
Dennoch musst Du natürlich irgendwie Dein Problem formulieren und wenn Du es nicht mit Quelltext machst, dann halt auf andere andere Art. Grafisch oder wie auch immer.

Ich denke, warum sich das nicht in der Breite bisher nicht durchsetzt ist zum einen, dass sich diese Tools nur allenfalls auf beschränkte Teilgebiete gut anwenden lassen. Darüber hinaus wirds schierig. Standardfälle lassen sich gut abdecken. Will man aber möglichst viel abdecken werden die Tools auch rasch sehr komplex, so dass Du allein schon zum beherrschen des Tools und der Anwendung der Tools kaum noch wirkliche Zeitersparnis hast.

Den anderen großen Aspekt den ich sehe ist die Tatsache, dass Du mit dem Quelltext eben sehr viel flexibler bist im Handling. Quelltext kann man kommentieren. Man kann auch schnell mal was testweise rauswerfen und später wieder hineintun.
Man kann Textprocessing-Tools drauf anwenden. All das geht mit Point&Klick-Tools eher schlecht.

Dazu kommt noch die Tatsache das man sich von dem Low-Code-Tool abhängig macht. Wenn Dir der GCC nicht passt kannst Du halt mit überschaubaren Aufwand zu Clang wechseln.
Beim Low-Code-Tool ist das i.d.R. schwieriger.
 
:-)

Apropos. Da fällt mir ein, dass ich die Bezeichnung Low Code ohnehin etwas gewöhnungsbedürftig finde.

Ich bin jetzt kein guter Kenner der englischen Sprache, aber für mich hört sich das komisch an und ich würde eher zur Bezeichnung Less Code tendieren.

....

Die tatsächliche Bedeutung ist völlig egal!

Es müssen Anglizismen, Abkürzungen oder Kunstwörter sein! Ideal ist immer eine Kombination aus allen drei Wortarten!

Mit anderen Worten - zu excellenten Bullshit gehören ganz viele Buzzwords!
 
Offensichtlich scheint agile Softwareentwicklung dann doch ihre Tücken zu haben und nicht wirklich zu funktionieren. Abgeleitet habe ich es aus diesem Heise Artikel:

Problem Agilität

Allerdings ist die Vorgehensweise des Erstellungsprozess wohl eng verwandt mit qualitätssichernden Maßnahmen, wie ich sie aus der QM und der ISO 9000 kenne . Kommt mir schon irgendwie vor wie alter Wein in neuen Schläuchen. Und das ist ja nicht grundlegend falsch, fortlaufend zu validieren und den Herstellungsprozess mit geeigneten Mitteln zu überwachen. Aber funktionieren sollte es schon .... am Ende geht es eh nicht nur um Qualität, sondern überwiegend um Kostenreduzierung.
 
Agil heißt im Kontext Softwareentwicklung hauptsächlich: es wird immer nur der nächste Sprint (z.B. 30 Tage) geplant und ohne Pflichten und Lastenheft gearbeitet. Der Auftraggeber ist also ständig in die Entwicklung involviert und kann bzw. muss regelmäßig seinen Input liefern. Tut er das nicht, geht auch nix voran. Man vermeidet damit eben, dass montatelang was entwickelt wird von dem der Auftraggeber dann behauptet, was ganz anderes bestellt zu haben. Oftmals verstehen die Entwickler ja auch was ganz anderes als der Auftraggeber, egal wie gut das Pflichtenheft ist. Oder es ist einfach nicht umsetzbar - so kann sehr früh darauf reagiert und gegengesteuert werden.

Aber ja: auch zu agiler Entwicklung gehört Disziplin :-)
 
qualitätssichernden Maßnahmen, wie ich sie aus der QM und der ISO 9000 kenne
Das QM oder dieses ISO-Gedöns irgendwas besser gemacht hätte als davor hab ich in der Praxis noch nicht wirklich beobachten können.

Vermutlich liegt das daran, dass man sich eher hinter Formalismen verstecken kann.
Früher war man einfach bemüht gute Arbeit abzuliefern. Und wenn man Sch***e gebaut hat wurde man dafür lang gemacht und gut war.
Heute kann man eben darauf verweisen, dass man doch alles nach dem vorgegebenen Prozess gemacht habe und daher gar nichts dafür kann, wenns am Ende nicht funktioniert.
Vor allem weil der Sinn mancher Vorgaben auch zweifelhaft ist, ganz einfach, weil die von jemanden stammt der von der eigentlichen Arbeit keine Ahnung hat.
Wenn was schief läuft und Du hast gegen die Vorgaben verstoßen dann hast Du halt wirklich ein Problem.

Das bringt die Leute dazu eher "Dienst nach Vorschrift" zu machen als wirklich das Problem zu lösen.

Das Problem mit Agilität ist, dass es oftmals nicht korrekt umgesetzt wird (das kommt ja auch im Artikel zur Sprache). Hinzu kommt, dass es nicht für jede Sache der richtige Ansatz ist.
 
Zurück
Oben