Warum wir seit 1969 jedes Jahrzehnt versuchen, Entwickler zu ersetzen

Das Muster, das alle frustriert

Der Traum entstand während der größten Errungenschaft der Menschheit

Als Neil Armstrong 1969 die Mondoberfläche betrat, erlebte die Welt, was organisierter menschlicher Erfindungsgeist erreichen konnte. Hinter dieser Errungenschaft stand Margaret Hamilton mit ihrem Team, das die Apollo-Software von Hand schrieb, kritische Fehler durch sorgfältige Prüfung erkannte und bewies, dass Software missionskritisch sein konnte.

Das Apollo-Programm demonstrierte, dass Software-Entwicklung wesentlich war, um das Unmögliche zu erreichen. Doch es offenbarte auch etwas, das die Unternehmensführung über Jahrzehnte frustrieren sollte: Software zu schreiben erforderte spezialisiertes Wissen, intensive Konzentration und erheblichen Zeitaufwand. Der Traum, es einfacher zu machen – weniger dieser teuren Spezialisten zu benötigen – begann fast sofort.

COBOL: Geschäftsleute schreiben ihre eigenen Programme

Ende der 1960er und in den 1970er Jahren entstand COBOL mit einem expliziten Ziel, das bereits im Namen stand: Common Business-Oriented Language. Die Vision war klar: Man macht die Sprache wie englische Sätze lesbar, und fachliche Experten würden ihre eigenen Programme schreiben. Keine spezialisierten Programmierer mehr nötig.

Diese Vision hatte echte Anziehungskraft. Software wurde für Geschäftsprozesse unverzichtbar, doch Programmierer blieben eine knappe und teure Ressource. COBOL versprach, Software-Entwicklung zu demokratisieren.

Was stattdessen geschah? COBOL wurde eine weitere Programmiersprache, die spezialisierte Ausbildung erforderte. Fachliche Experten, die versuchten, COBOL zu schreiben, entdeckten schnell, dass lesbare Syntax die Komplexität von Logik, Datenstrukturen oder Systemdesign nicht beseitigte. Eine neue Klasse von COBOL-Programmierern entstand, und der Traum, spezialisierte Entwickler zu eliminieren, blieb unerfüllt.

Doch der Traum starb nicht. Er wartete einfach auf die nächste technologische Welle.

Die 1980er: CASE-Tools generieren alles

Computer-Aided Software Engineering-Tools kamen in den 1980er Jahren mit gewaltigen Versprechen. Man zeichnete Flussdiagramme und Entity-Relationship-Diagramme, und das Tool würde funktionierenden Code generieren. Die Marketing-Botschaft fand Anklang: Visuelles Design war intuitiver als das Tippen kryptischer Befehle. Fachliche Experten konnten ihre Prozesse modellieren, und Software würde entstehen.

Organisationen investierten massiv. Anbieter versprachen Produktivitätssteigerungen von 10x oder mehr. Doch die meisten CASE-Tool-Initiativen scheiterten oder hatten große Schwierigkeiten.

Der generierte Code erforderte oft erhebliche manuelle Eingriffe. Performance-Probleme traten auf. Die Wartung wurde zum Albtraum, wenn generierter Code von den visuellen Modellen abwich. Am kritischsten: Das Zeichnen akkurater Diagramme erforderte das Verständnis derselben logischen Komplexität, die das Programmieren verlangte. Das Tool änderte die Schnittstelle, nicht aber die grundlegende Herausforderung.

Wieder erwies sich das Problem als hartnäckiger als die Lösung.

Visual Basic und Delphi: Ziehen, Ablegen, Fertig

Die 1990er brachten einen anderen Ansatz. Microsofts Visual Basic und Borlands Delphi machten das Erstellen von Benutzeroberflächen dramatisch einfacher. Man zog Komponenten auf ein Formular, setzte Eigenschaften, schrieb Event-Handler. Plötzlich fühlte sich das Erstellen einer Windows-Anwendung für Entwickler mit bescheidener Erfahrung erreichbar an.

Diese Welle war anders erfolgreich als COBOL oder CASE-Tools. Diese Umgebungen erkannten an, dass Programmierkenntnisse noch nötig waren, aber sie senkten die Einstiegshürde. Eine breitere Gruppe von Menschen konnte nützliche Anwendungen erstellen.

Doch der Traum, Entwickler zu eliminieren, bestand fort. „Power Users” und „Citizen Developers” würden Abteilungsanwendungen bauen. IT-Abteilungen könnten sich auf Infrastruktur konzentrieren, während Geschäftsbereiche ihre eigenen Software-Bedürfnisse lösten.

Die Realität erwies sich als nuancierter. Einfache Anwendungen waren tatsächlich für mehr Menschen zugänglich. Doch sobald die Anforderungen an Komplexität zunahmen – Integration mit bestehenden Systemen, Sicherheitsüberlegungen, Performance unter Last, langfristige Wartung – wurde der Bedarf an erfahrenen Entwicklern evident. Die Tools erweiterten, wer Software schreiben konnte, aber sie beseitigten nicht die für substanzielle Systeme erforderliche Expertise.

Und so setzte sich der Zyklus ins neue Jahrtausend fort.

Die 2000er und darüber hinaus: Web-Frameworks, Low-Code und No-Code

Jedes nachfolgende Jahrzehnt führte neue Varianten ein. Ruby on Rails versprach Convention over Configuration. Low-Code-Plattformen boten visuelle Entwicklung mit minimalem Programmieren. No-Code-Plattformen behaupteten, Programmierung für gängige Geschäftsanwendungen vollständig zu eliminieren.

Jede Welle lieferte echten Wert. Die Entwicklung wurde in spezifischen Kontexten tatsächlich schneller. Mehr Menschen konnten an der Erstellung von Software-Lösungen teilnehmen. Doch professionelle Entwickler blieben unverzichtbar, und die Nachfrage nach ihren Fähigkeiten wuchs weiter, anstatt zu schrumpfen.

Was uns zur Frage bringt: Warum wiederholt sich dieses Muster?

Warum der Traum fortbesteht

Das wiederkehrende Muster offenbart etwas Wichtiges darüber, wie wir über Komplexität denken. Software-Entwicklung sieht so aus, als sollte sie einfach sein, weil wir beschreiben können, was wir in einfacher Sprache wollen. „Wenn ein Kunde eine Bestellung aufgibt, prüfe Lagerbestand, berechne Versand, verarbeite Zahlung und sende Bestätigungs-E-Mail.” Diese Beschreibung klingt unkompliziert.

Die Komplexität zeigt sich in den Details. Was passiert, wenn Lagerbestand temporär durch eine andere Bestellung reserviert ist? Wie handhabt man Teilzahlungen? Was, wenn der E-Mail-Service vorübergehend nicht verfügbar ist? Sollte man erneut versuchen? Wie oft? Was, wenn die Sitzung des Kunden während des Checkouts abläuft? Wie verhindert man doppelte Bestellungen?

Jede Antwort führt zu mehr Fragen. Die akkumulierten Entscheidungen, Randfälle und Interaktionen schaffen echte Komplexität, die kein Tool oder keine Sprache eliminieren kann. Jemand muss diese Szenarien durchdenken. Dieses Denken ist Software-Entwicklung, unabhängig davon, ob es in COBOL, einem CASE-Tool-Diagramm, Visual Basic oder einem KI-Prompt ausgedrückt wird.

Was uns zur heutigen Begeisterung bringt.

KI: Das neueste Kapitel einer langen Geschichte

Heutige KI-Programmierassistenten repräsentieren den bisher leistungsfähigsten Versuch, bei der Software-Entwicklung zu unterstützen. Sie können erhebliche Mengen funktionierenden Code aus natürlichsprachlichen Beschreibungen generieren. Sie können bestehenden Code erklären, Verbesserungen vorschlagen und beim Debugging helfen.

Das stellt echten Fortschritt dar. Die Unterstützung ist real und wertvoll. Erfahrene Entwickler nutzen diese Tools, um effizienter zu arbeiten. Menschen, die Programmieren lernen, finden die interaktive Anleitung hilfreich.

Doch wir sehen bereits das vertraute Muster auftreten. Die anfängliche Begeisterung, dass KI Entwickler ersetzt, weicht einem nuancierteren Verständnis: KI verändert, wie Entwickler arbeiten, anstatt den Bedarf an ihrem Urteilsvermögen zu eliminieren. Die Komplexität bleibt. Jemand muss das Geschäftsproblem verstehen, bewerten, ob der generierte Code es korrekt löst, Sicherheitsimplikationen bedenken, sicherstellen, dass er sich ordnungsgemäß in bestehende Systeme integriert, und ihn warten, während sich Anforderungen weiterentwickeln.

KI verstärkt die Fähigkeiten von Entwicklern. Sie ersetzt nicht den Bedarf an Menschen, die sowohl den Problembereich als auch die technische Landschaft verstehen.

So viele Möglichkeiten, immer noch kämpfend

Hier ist das Paradoxon, das dieses Muster besonders schmerzlich macht. Wir haben außerordentlichen Fortschritt in Software-Fähigkeiten gemacht. Der Apollo-Computer hatte 4 KB RAM. Ihr Smartphone hat millionenfach mehr Rechenleistung. Wir haben Tools und Frameworks gebaut, die viele Aspekte der Entwicklung tatsächlich einfacher machen.

Doch die Nachfrage nach Software übersteigt bei weitem unsere Fähigkeit, sie zu erstellen. Jede Organisation benötigt mehr Software, als sie bauen kann. Der Rückstand an gewünschten Features und neuen Initiativen wächst schneller, als Entwicklungsteams ihn bewältigen können.

Diese Spannung – leistungsstarke Tools, aber unzureichende Kapazität – hält den Traum am Leben. Die Unternehmensführung schaut auf den Rückstand und denkt: „Es muss einen Weg geben, schneller zu werden, mehr Menschen zur Mitwirkung zu befähigen.” Das ist ein vernünftiger Gedanke. Er führt natürlich zu Enthusiasmus für jedes Tool oder jeden Ansatz, der verspricht, Software-Entwicklung zu demokratisieren.

Die Herausforderung ist, dass Software-Entwicklung nicht primär durch Tippgeschwindigkeit oder Syntaxkenntnisse begrenzt ist. Sie ist begrenzt durch das Denken, das erforderlich ist, um Komplexität gut zu handhaben. Schnelleres Tippen hilft nicht, wenn man durchdenkt, wie man gleichzeitige Datenbankaktualisierungen handhabt. Einfachere Syntax hilft nicht, wenn man über Sicherheitsimplikationen nachdenkt.

Was sollten Führungskräfte also mit diesem Verständnis tun?

Was das für Führungskräfte bedeutet

Das Verständnis dieses Musters verändert, wie man neue Tools und Ansätze bewertet. Wenn jemand verspricht, dass seine Plattform es Geschäftsanwendern ermöglicht, Anwendungen ohne Entwickler zu bauen, kann man die Ambition würdigen und gleichzeitig realistische Erwartungen behalten.

Die richtige Frage ist nicht „Wird das unseren Bedarf an Entwicklern eliminieren?” Die richtigen Fragen sind:

• Wird das unseren Entwicklern helfen, effektiver an komplexen Problemen zu arbeiten?
• Wird das uns ermöglichen, bestimmte Arten von Lösungen schneller zu bauen?
• Reduziert das die für repetitive Aufgaben aufgewendete Zeit, sodass sich Entwickler auf einzigartige Herausforderungen konzentrieren können?
• Wird unser Team neue Fähigkeiten erlernen müssen, um das effektiv zu nutzen?

Diese Fragen erkennen an, dass Entwicklung unreduzierbare Komplexität beinhaltet, während sie offen für Tools bleiben, die echte Hebelwirkung bieten.

Und sie weisen auf etwas Tieferes über die Natur von Software-Entwicklung hin.

Das Muster offenbart die Natur des Problems

Dieses fünfzigjährige Muster lehrt uns etwas Grundlegendes über Software-Entwicklung selbst. Wäre das Problem primär mechanisch – zu viel Tippen, zu komplexe Syntax, zu viele Schritte – hätten wir es inzwischen gelöst. COBOL machte Syntax lesbar. CASE-Tools eliminierten Tippen. Visuelle Tools eliminierten Syntax. KI kann jetzt ganze Funktionen aus Beschreibungen generieren.

Jeder Fortschritt adressierte einen echten Reibungspunkt. Doch die grundlegende Herausforderung besteht fort, weil sie nicht mechanisch ist. Sie ist intellektuell. Software-Entwicklung ist Denken, das greifbar gemacht wird. Die Artefakte, die wir erstellen – ob COBOL-Programme, Delphi-Formulare oder Python-Skripte – sind das sichtbare Ergebnis unsichtbaren Nachdenkens über Komplexität.

Man kann dieses Nachdenken nicht abkürzen, genauso wenig wie man das Nachdenken abkürzen kann, das erforderlich ist, um ein Gebäude zu entwerfen oder eine medizinische Diagnose zu stellen. Bessere Tools helfen. Erfahrung hilft. Aber jemand muss es noch durchdenken.

Wie sollten wir also vorgehen, im Wissen um all das?

Mit klarem Blick vorangehen

Die nächste Welle von Entwicklungs-Tools wird kommen. Einige werden echten Wert liefern. Einige werden vertraute Versprechen mit neuer Technologie wiederholen. Perspektive auf dieses wiederkehrende Muster zu haben, hilft, produktiv mit neuen Tools umzugehen.

Nutzen Sie KI-Assistenten. Bewerten Sie Low-Code-Plattformen. Experimentieren Sie mit neuen Frameworks. Aber investieren Sie primär in die Fähigkeit Ihrer Mitarbeiter, klar über Komplexität nachzudenken. Diese Fähigkeit bleibt der einschränkende Faktor, genau wie beim Apollo-Programm.

Die Mondlandung geschah, weil brillante Menschen sorgfältig über jedes Detail einer außerordentlich komplexen Herausforderung nachdachten. Sie schrieben Software von Hand, weil das das verfügbare Werkzeug war. Hätten sie bessere Tools gehabt, hätten sie sie gerne genutzt. Aber die Tools hätten nicht ihren Bedarf eliminiert, die Komplexität zu durchdenken.

Wir befinden uns immer noch in derselben grundlegenden Situation. Wir haben bessere Tools – erheblich bessere Tools – aber das Denken bleibt unverzichtbar.

Der Traum erfüllt einen Zweck

Vielleicht ist der wiederkehrende Traum, Entwickler zu ersetzen, kein Fehler. Vielleicht ist es ein notwendiger Optimismus, der Tool-Entwicklung vorantreibt. Jeder Versuch, Entwicklung zugänglicher zu machen, produziert Tools, die tatsächlich helfen. Der Traum wird nicht wie vorgestellt wahr, aber ihn zu verfolgen schafft Wert.

COBOL ließ fachliche Experten keine Programme schreiben, aber es ermöglichte einer Generation von Entwicklern, Geschäftssysteme effektiv zu bauen. CASE-Tools generierten keine vollständigen Anwendungen, aber sie brachten unser Denken über visuelle Modellierung voran. Visual Basic eliminierte keine professionellen Entwickler, aber es brachte Anwendungsentwicklung zu mehr Menschen. KI wird Entwickler nicht ersetzen, aber sie wird auf bedeutsame Weise ändern, wie wir arbeiten.

Das Muster setzt sich fort, weil der Traum einen legitimen Bedarf widerspiegelt. Wir benötigen tatsächlich schnellere, effizientere Wege, Software zu erstellen. Wir entdecken nur immer wieder, dass die Einschränkung nicht das Tool ist – es ist die Komplexität der Probleme, die wir zu lösen versuchen.

Das zu verstehen bedeutet nicht, neue Tools abzulehnen. Es bedeutet, sie mit klaren Erwartungen darüber zu nutzen, was sie liefern können und was immer menschliches Urteilsvermögen erfordern wird.