Softwareentwicklung automatisieren

7 Wege, Ihr Development zu lähmen

12.02.2024
Von 
Peter Wayner schreibt unter anderem für unsere US-Schwesterpublikation InfoWorld.com und ist Autor verschiedener Bücher - unter anderem zu den Themen Open Source Software, autonomes Fahren und digitale Transaktionen.
Der Traum von der vollständig automatisierten Softwareentwicklung ist in der Realität oft schnell ausgeträumt.
Automatisierungsinitiativen halten auch im Bereich der Softwareentwicklung etliche Fallstricke bereit.
Automatisierungsinitiativen halten auch im Bereich der Softwareentwicklung etliche Fallstricke bereit.
Foto: DC Studio - shutterstock.com

Welcher Dev träumt nicht davon, am Pool zu prokrastinieren, während Generative-AI- und Low-Code-Tools den Enterprise Stack am Laufen halten? Es ist ein schöner Traum, der beim Blick auf die Realität schnell platzt: Keines der aktuellen Werkzeuge ist ausgereift genug, um menschliche Interaktion im Bereich der Softwareentwicklung komplett überflüssig zu machen. Bislang funktioniert das nur in einigen Teilbereichen.

Allerdings können diese Tools und Automatisierungsinitiativen auch am Ziel vorbeischießen. Und wenn sie das tun, drohen mindestens unschöne Konsequenzen - mitunter auch Katastrophen. Die folgenden sieben Wege führen direkt ins Development-Automatisierungsverderben.

1. Garbage Collection

In der Theorie ist die Zuweisung von Speicher etwas, über das sich Softwareentwickler keine Gedanken machen müssen. Die meisten modernen Programmiersprachen verfügen über einen Layer, der das automatisiert erledigt - die Garbage Collection (GC). Sie hat auch dafür gesorgt, dass Memory Leaks weitestgehend der Vergangenheit angehören. Das führt bei einigen Programmierern zu der Annahme, dass diese nun eine Sache für die GC sind. Statt manuell nach falsch zugewiesenen Daten zu suchen, wird in vielen Fällen einfach der RAM des Cloud-Servers erhöht. Es gibt weitere Probleme mit der automatischen Speicherverwaltung: Die Zuweisung von Objekten ist einer der größten Zeitfresser, weswegen smarte Programmierer dazu übergangen sind, zu Beginn ein Objekt zuzuweisen - und dieses dann wiederzuverwenden.

Ein allgemeineres Problem in diesem Zusammenhang ist die Frage, warum die Garbage Collection immer zum ungünstigsten Zeitpunkt erfolgt. Dafür sind Automatisierungsroutinen verantwortlich - die GC kann nicht "wissen", wann Latenzen das Nutzererlebnis ruinieren.

2. Interpretierter Code

Diverse Skriptsprachen haben die Softwareentwicklung geöffnet und es einfacher gemacht, einen Einstieg in Sachen Coding zu finden. Das begeistert nicht nur Vollzeit-Programmierer, sondern auch Experten in angrenzenden Bereichen - etwa Datenwissenschaftler. Nicht ohne Grund gehört etwa Python zu den aktuell populärsten Programmiersprachen.

Der Grad an Automatisierung, den interpretierte Sprachen wie Python mitbringen, erleichtert zwar den Umgang mit ihnen, kann jedoch auch Ineffizienzen und Security-Probleme verursachen. Zudem sind interpretierte Programmiersprachen in der Regel deutlich langsamer. Die Kombination aus automatisiertem Memory Management, wenig Zeit für Optimierungen und Runtime Interpretation kann sich als echter Bremsklotz erweisen.

Abhilfe kann an dieser Stelle ein guter Just-in-Time (JIT)-Compiler schaffen. Python-Entwickler können zum Beispiel Jython verwenden, das über einen integrierten Java-basierten, JIT-Compiler verfügt. PHP und Python haben jedoch auch ihre eigenen JIT-Compiler wie PyPy, Numba und Pyston (um nur einige zu nennen). Dennoch: Die Möglichkeiten eines Interpreters sind begrenzt.

Zudem kann die bei interpretierten Sprachen beliebte Dynamic-Typing-Funktionalität Injection-Attacken und ähnlichen Angriffsformen zuträglich sein. Was nun nicht heißen soll, dass kompilierter Code nicht auch anfällig wäre. Softwareentwickler sollten generell wachsam bleiben - ganz egal, welche Sprache sie verwenden.

3. Künstliche Intelligenz

Künstliche Intelligenz (KI) ist ein weit größeres Thema als Automatisierung, das mit zahlreichen Schattenseiten einhergeht. Auch wenn die Technologie teilweise als Heilsbringer gepriesen wird: Die Ergebnisse, die sie liefert, wirken - wenn man die Hype-Brille einmal ablegt - eher fade und wiedergekäut. Letztendlich geben Large Language Models nicht viel mehr als massiv skalierte Durchschnittswerte ihrer Trainingsdaten wieder.

Und KI kann durchaus auch für Probleme im Bereich der Softwareentwicklung sorgen - etwa wenn sie zufällige Fehler einstreut, beziehungsweise halluziniert. KI-Tools sollten deswegen weniger als omnipotente Werkzeuge und mehr als semi-schlaue Assistenten für smarte und agile menschliche Experten betrachtet werden.

4. Datenbankabfragen

Im Grunde ist die Datenbank das ursprünglichste Automatisierungs-Tool, über das wir verfügen. Oracle bezeichnet seine Datenbanken sogar als "autonom", um zu unterstreichen, wie weit die Automatisierung geht. Moderne Unternehmen wären ohne die "Magie" großer Datenbanken nicht mehr funktionsfähig. Speziell die Softwareentwicklungs-Teams lernen dabei jedoch schnell: Die Plattformen haben Grenzen. Manche Abfrage-Engines sind viel zu komplex, was dazu führt, dass Queries von Entwicklern viel Zeit beanspruchen. Dazu kommt, dass es diffizil sein kann, komplexe SQL-Abfragen zu schreiben, die gleichzeitig auch effizient sind.

Manche Teams können es sich leisten, spezialisierte Datenbankadministratoren einzustellen, die dann dafür sorgen, dass die Daten reibungslos fließen. Diese Spezialisten passen die Parameter an und stellen sicher, dass genügend Arbeitsspeicher vorhanden ist, um die Indizes zu verarbeiten, ohne dass es zu Ausfällen kommt.

5. Low-Code

Einige Enterprise-Tools, -Portale und -Webanwendungen sind inzwischen so ausgereift, dass sie sich im Handumdrehen anpassen lassen - mit wenig bis gar keinem Programmieraufwand. Das nennt man im Vertriebssprech dann "Low-Code" oder "No Code" - was teilweise korrekt ist, weil der Automatisierungsgrad dieser Lösungen relativ hoch ist, aber den Eindruck vermitteln kann, dass hierbei keinerlei Probleme zu erwarten sind.

Das erste und allgemeine Problem an solchen Lösungen: Jedes Unternehmen bringt seine eigenen Voraussetzungen mit. Low-Code- und No-Code-Plattformen bieten jedoch ein einheitliches System, in dem alle Anpassungen in der Regel nur oberflächlich erledigt werden. Der zugrundeliegende, generalisierte Code ist dabei oft wesentlich langsamer, als er sein könnte, weil sämtliche Eventualitäten abgedeckt sein und deshalb kontinuierlich Daten geprüft und (re)formatiert werden müssen. Kommen neue Informationen hinzu, muss der "Glue Code", der automatisiert Verbindungen herstellt, jedes Mal neu ausgeführt werden. Das treibt die Hardwarekosten und kann zu erheblichen Slowdowns führen.

6. RPA

Eine mit Low-Code und No Code verwandte Technologie ist Robotic Process Automation (RPA). Sie hat in den Bürolandschaften Einzug gehalten, um gewöhnliche Office-Tasks wie Dokumentenmanagement zu automatisieren. Dabei kombinieren RPA-Tools leider die potenziellen Probleme von KI- und Low-Code-Tools.

Ein wesentliches Verkaufsargument für RPA-Lösungen: Sie können eine moderne Schnittstelle für ältere Systeme bereitstellen und gleichzeitig Integration bieten. Das ist unter Umständen ein schneller Weg zu einem modernen "Gesicht", ohne den zugrundeliegenden, alten Code zu verändern. Das ist dann ein bisschen so, als wäre RPA ein technologisches Panzerband, mit dem man kaum noch laufenden Legacy-Code zusammenhält.

Zur Gefahr wird das insbesondere dann, wenn die Automatisierung als selbstverständlich hingenommen wird und keinerlei manuelle Überprüfung mehr stattfindet. Es ist verlockend, Dinge mit einem Knopfdruck erledigen zu können, kann jedoch auch schnell zu folgenschweren Fehlern führen.

7. Automatisierungsabsenz

Das Einzige, was noch schlimmer ist als zu viel Automatisierung, ist gar keine Automatisierung. Das führt zu Software-Stacks, die irgendwann so veraltet sind, dass es sich nicht mehr lohnt, sie zu aktualisieren - sprich technischen Schulden. Ein vor sich hinsiechender Tech-Stack wirkt sich negativ auf alle Beteiligten aus, denn er ist maßgeblich für die Workflows im Unternehmen.

Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation Infoworld.