Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Lesedauer 3 Min.

Grund zur Sorge?

Low Code und No Code wollen Softwareentwicklung demokratisieren. Welche Auswirkungen hat dies für Softwareentwickler:innen?
Low-Code- und No-Code-Plattformen entstanden aus dem Wunsch, Geschäftsprozesse unabhängig von knappen Ressourcen schnell und flexibel in Software abbilden zu können. Angesichts immer kürzerer Innovationszyklen sollen sie Fachanwender:innen in die Lage versetzen, Anwendungen zu entwickeln, ohne selbst programmieren zu müssen.Tatsächlich ermöglichen Tools wie Mendix, Appian und Co. eine schnellere Erstellung von Prototypen, Apps und Workflows. Sie beschleunigen die Digitalisierung der Geschäftsprozesse in Unternehmen, entlasten professionelle Entwicklerteams bei Routineaufgaben, senken dank visueller Interfaces, Drag-and-Drop-Funktionalität und vorgefertigter Module Einstiegshürden für Laien und fördern die Zusammenarbeit zwischen Fachabteilungen einerseits und der Softwareentwicklung andererseits – Letzteres ist aus meiner Sicht ein nicht zu unterschätzender Vorteil in einer zunehmend interdisziplinären Arbeitswelt.

„Low Code/No Code kann den Entwicklungsaufwand signifikant reduzieren – für alle Beteiligten.“

Allerdings ist das nicht die ganze Wahrheit, denn mitunter sind Skalier- und Wartbarkeit, Performance und Sicherheit nicht immer auf höchstem Niveau. Außerdem stößt man an Grenzen, wenn es um eine spätere Überführung in klassische Softwarearchitekturen geht. Und auch die Frage nach Governance, Versionierung, Testing und Integration in bestehende DevOps-Prozesse ist nicht geklärt.Die Integration künstlicher Intelligenz kann hier zwar zusätzliche Potenziale schaffen, etwa bei der automatischen Generierung von Logik, der Optimierung von Datenmodellen oder der Erstellung verteilter Anwendungen. Aber: Je höher die Anforderungen an die Software, desto höher auch ihre Komplexität.Die Sorge, dass Low Code und No Code Entwickler:innen überflüssig machen könnten, scheint mir deshalb unangebracht. Komplexe Systeme bedürfen tiefgehender technischer Expertise und jahrelanger Erfahrung in der professionellen Softwareentwicklung. Und schließlich müssen auch die Low-Code- und No-Code-Werkzeuge selbst gepflegt und aktiv weiterentwickelt werden. In meinen Augen sind dies positiv herausfordernde und motivierende Perspektiven.Ich wünsche Ihnen eine schöne Zeit mit der neuen dotnetpro!HerzlichstFernando SchneiderChefredakteur dotnetpro
Miscellaneous

Neueste Beiträge

SQLite als Dokumentenspeicher: Kann das gut gehen? - SQLite für .NET-Entwickler, Teil 5
Die Embedded SQL-Datenbank SQLite kann auch als objektorientierte Datenbank beziehungsweise Dokumentenspeicher genutzt werden – nach Konzepten also, wie sie NoSQL-Datenbanken wie MongoDB einsetzen.
6 Minuten
29. Apr 2026
Mit SQL Server 2025 HTTP-APIs aufrufen - Neues in SQL Server 2025, Teil 1
API-Aufrufe mit SQL Server 2025 sind kein Spielzeug, sondern ein ernst zu nehmender Integrationsmechanismus.
6 Minuten
Deep Learning in .NET – TensorFlow.NET und TorchSharp - .NET, Python und KI, Teil 3
Mit modernen KI-Frameworks lassen sich Deep-Learning-Modelle direkt in C# entwickeln.
6 Minuten

Das könnte Dich auch interessieren

Elektronische Schaltkreise im Browser simulieren - Simulation
Statt mit Steckfeld oder Lötkolben kann man auf dieser Website Schaltungen per Drag and Drop zusammenstellen und deren Verhalten testen.
2 Minuten
26. Jul 2018
UIs für Linux - Bedienoberflächen entwickeln mithilfe von C#, .NET und Avalonia
Es gibt viele UI-Frameworks für .NET, doch nur sehr wenige davon unterstützen Linux. Avalonia schafft als etabliertes Open-Source-Projekt Abhilfe.
16 Minuten
16. Jun 2025
C#-.NET-Apps mit WinUI 3 - Komponentenbasierte Apps mit Fluent/FAST, Teil 3
Microsoft macht mit WinUI 3 ein natives User-Experience-Framework für Windows verfügbar, dessen Komponenten auf dem Microsoft-eigenen Design-System Fluent 2 basieren.
23 Minuten
13. Mai 2024
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige