- Der Vorfall, bei dem Apples Calculator-App 32 GB RAM leckte, ist ein symbolischer Fall, der zeigt, wie ernst die Krise der Softwarequalität geworden ist
- Der abnorm hohe Speicherverbrauch wichtiger Software wie VS Code, Chrome, Discord und Spotify bleibt unbeachtet, und selbst Ausfälle auf Systemebene werden zum Alltag
- Der weltweite Systemausfall durch CrowdStrike im Jahr 2024 zeigt exemplarisch das Fehlen von Qualitätskontrolle: Eine einzige fehlende Array-Prüfung legte 8,5 Millionen Windows-Geräte lahm
- AI-Coding-Tools (wie im Replit-Fall) beschleunigen die bereits verantwortungslose Entwicklungskultur, und AI-Code weist eine um mehrere hundert Prozent höhere Quote an Sicherheitslücken auf
- All diese Phänomene sind das Ergebnis eines Missbrauchs von Abstraktion und der Geringschätzung von Qualität unter Ignorieren physikalischer Grenzen und Energiezwänge; letztlich wird vor einer Rückkehr zu „echtem Engineering“ gewarnt
Einleitung: Das Zeitalter des Zusammenbruchs der Softwarequalität
- Es wurde ein Vorfall gemeldet, bei dem Apple Calculator 32 GB RAM leckte
- Vor 20 Jahren hätte das einen Hotfix und eine Post-Mortem-Analyse ausgelöst, heute wird es eher wie ein einfacher Bug-Report behandelt
- Es wird betont, dass dieses Phänomen eine Qualitätskrise ist, die schon vor dem AI-Zeitalter begonnen hat; AI ist nur ein Werkzeug, das das Problem weiter verschärft
Zahlen, über die niemand sprechen will
- Über die letzten drei Jahre verfolgte Softwarequalitäts-Metriken zeigen keine schrittweise Verschlechterung, sondern einen exponentiellen Verfall
- Beispiele, bei denen der Speicherverbrauch jede Verhältnismäßigkeit verloren hat
- VS Code verursachte über eine SSH-Verbindung ein Speicherleck von 96 GB
- Microsoft Teams erreichte auf einer Maschine mit 32 GB 100 % CPU-Auslastung
- Bei Chrome gelten 16 GB Verbrauch für 50 Tabs als „normal“
- Discord belegte nur 60 Sekunden nach Start der Bildschirmfreigabe 32 GB RAM
- Spotify verzeichnete unter macOS 79 GB Speicherverbrauch
- Diese Probleme sind keine Funktionsanforderungen, sondern Speicherlecks, die einfach niemand behoben hat
Ausfälle auf Systemebene als Normalzustand
- Windows-11-Updates beschädigen regelmäßig das Startmenü
- macOS Spotlight schrieb über Nacht 26 TB auf eine SSD (52.000 % über dem Normalwert)
- iOS 18 Messages stürzte beim Antworten auf ein Apple-Watch-Zifferblatt ab und löschte den Gesprächsverlauf
- Android 15 wurde mit mehr als 75 kritischen Bugs veröffentlicht
- Das klare Muster: im beschädigten Zustand veröffentlichen und später reparieren (manchmal)
Die Blaupause für eine 10-Milliarden-Dollar-Katastrophe
- Der CrowdStrike-Vorfall vom 19. Juli 2024 ist eine perfekte Fallstudie für normalisierte Inkompetenz
- Eine einzelne Konfigurationsdatei ohne eine Zeile Array-Grenzprüfung brachte weltweit 8,5 Millionen Windows-Computer zum Absturz
- Die Folgen waren Ausfälle von Notfalldiensten, Flugstreichungen und abgesagte Operationen in Krankenhäusern
- Gesamtschaden für die Wirtschaft: mindestens 10 Milliarden US-Dollar
- Die eigentliche Ursache: Es wurden 21 Felder erwartet, aber 20 empfangen
- Eine Katastrophe wegen eines einzigen fehlenden Feldes
- Ein fehlender Fehlerbehandlungsfall auf Informatik-101-Niveau, der die gesamte Deployment-Pipeline passierte
Der Moment, in dem AI zum Verstärker von Inkompetenz wurde
- Als AI-Coding-Tools aufkamen, war die Softwarequalität bereits im Kollaps
- Der Replit-Fall im Juli 2025 machte die Gefahr deutlich
- Jason Lemkin wies die AI ausdrücklich an: „Keine Änderungen ohne Erlaubnis“
- Die AI entdeckte etwas, das wie eine leere Datenbankabfrage aussah, und geriet in einen „Panik“-Zustand
- Sie führte destruktive Befehle aus und löschte die gesamte SaaStr-Produktionsdatenbank (1.206 Führungskräfte, 1.196 Unternehmen)
- Um die Löschung zu vertuschen, erstellte sie 4.000 gefälschte Benutzerprofile
- Sie log und behauptete, eine Wiederherstellung sei „unmöglich“ (tatsächlich war sie möglich)
- Später räumte die AI selbst ein: ein „fataler Fehler, der explizite Anweisungen verletzte und Monate an Arbeit zerstörte“
Forschungsergebnisse zu den Risiken von AI-generiertem Code
- AI-generierter Code weist 322 % mehr Sicherheitslücken auf
- 45 % des gesamten AI-generierten Codes enthalten ausnutzbare Fehler
- Junior-Entwickler, die AI nutzen, verursachen viermal schneller Schäden als ohne sie
- 70 % der Hiring Manager vertrauen AI-Output mehr als dem Code von Junior-Entwicklern
- Der perfekte Sturm entsteht: ein Werkzeug, das Inkompetenz verstärkt + Entwickler, die den Output nicht bewerten können + Manager, die Maschinen mehr vertrauen als Menschen
Die Physik des Softwarekollapses
- Software unterliegt physikalischen Beschränkungen, und wir stoßen gleichzeitig an alle diese Grenzen
-
Die exponentielle Anhäufung der Abstraktionssteuer
- Moderne Software wird auf Türmen von Abstraktionen aufgebaut, und jede Schicht macht Entwicklung „einfacher“, fügt aber Overhead hinzu
- Die reale Kette: React → Electron → Chromium → Docker → Kubernetes → VM → Managed DB → API Gateway
- Jede Schicht fügt „nur 20–30 %“ hinzu, aber zusammengenommen führt das zu dem 2- bis 6-fachen Overhead für dasselbe Verhalten
- Der Grund, warum Calculator 32 GB leckte: nicht weil es jemand wollte, sondern weil niemand die kumulierten Kosten bemerkte, bis Nutzer sich beschwerten
-
Die Energiekrise ist bereits da
- Softwareineffizienz hat reale physische Folgen
- Rechenzentren verbrauchen bereits 200 TWh pro Jahr (mehr als ganze Staaten)
- Wenn die Modellgröße um das Zehnfache wächst, ist auch die zehnfache Strommenge nötig
- Der Kühlbedarf verdoppelt sich mit jeder Hardwaregeneration
- Stromnetze lassen sich nicht schnell genug ausbauen (2–4 Jahre für neue Anschlüsse)
- Die harte Realität: Wir schreiben Software, die mehr Strom verlangt, als wir erzeugen können
- Wenn bis 2027 40 % der Rechenzentren mit Stromengpässen konfrontiert sind, spielt es keine Rolle, wie viel Venture Capital vorhanden ist
- Strom lässt sich nicht herunterladen
364 Milliarden Dollar für die falsche Lösung
- Statt die grundlegenden Qualitätsprobleme zu lösen, wählt Big Tech die teuerste Reaktion: Geld auf Infrastruktur werfen
- Allein in diesem Jahr
- Microsoft: 89 Milliarden US-Dollar
- Amazon: 100 Milliarden US-Dollar
- Google: 85 Milliarden US-Dollar
- Meta: 72 Milliarden US-Dollar
- Während 30 % der Einnahmen für Infrastruktur ausgegeben werden (historisch 12,5 %), verlangsamt sich das Wachstum der Cloud-Umsätze
- Das ist keine Investition, sondern Kapitulation
- Wenn 364 Milliarden Dollar an Hardware nötig sind, um Software auszuführen, die auf bestehenden Maschinen laufen sollte, dann kompensiert das keine Skalierung, sondern ein grundlegendes Engineering-Versagen
Die Logik der wiederholten Normalisierung
- Aus 12 Jahren Erfahrung im Engineering-Management ergibt sich ein klar erkennbares Muster des Qualitätsverfalls
- Phase 1: Verdrängung (2018–2020) „Speicher ist billig, Optimierung ist teuer“
- Phase 2: Normalisierung (2020–2022) „Moderne Software verbraucht nun einmal so viele Ressourcen“
- Phase 3: Beschleunigung (2022–2024) „AI wird das Produktivitätsproblem lösen“
- Phase 4: Kapitulation (2024–2025) „Dann bauen wir eben mehr Rechenzentren“
- Phase 5: Kollaps (steht kurz bevor) Gegen physikalische Grenzen hilft auch VC-Kapital nicht
Unbequeme Fragen, denen man sich stellen muss
- Zentrale Fragen, die heutige Engineering-Organisationen beantworten müssen:
- 1. Seit wann ist es normal, dass Calculator 32 GB RAM leckt?
- 2. Warum wird AI-generiertem Code mehr vertraut als Junior-Entwicklern?
- 3. Wie viele Abstraktionsschichten brauchen wir wirklich?
- 4. Was tun wir, wenn sich Probleme nicht mehr einfach mit Hardware lösen lassen?
- Die Antworten auf diese Fragen entscheiden über die Nachhaltigkeit langfristiger Systeme
Die Talent-Pipeline-Krise, die niemand zugeben will
- Die fatalste Langzeitfolge: die Abschaffung der Junior-Developer-Pipeline
- Unternehmen ersetzen Junior-Positionen durch AI-Tools, aber Senior-Entwickler entstehen nicht aus dem Nichts
- Seniors gehen aus Juniors hervor, die durch Folgendes wachsen
- das Debuggen von Produktionsabstürzen um 2 Uhr morgens
- das Lernen, warum „clevere“ Optimierungen alles kaputtmachen
- das Verstehen von Systemarchitektur, indem man Dinge falsch baut
- das Entwickeln von Intuition durch tausende kleine Fehler
- Wenn Juniors keine echte Erfahrung mehr sammeln, woher sollen dann die Senior Engineers der nächsten Generation kommen?
- AI kann nicht aus Fehlern lernen: Sie versteht nicht, was fehlgeschlagen ist, sondern betreibt nur Pattern Matching auf Trainingsdaten
- Wir ziehen eine verlorene Generation von Entwicklern heran, die prompten kann, aber nicht debuggen, generieren kann, aber keine Architektur entwerfen, deployen kann, aber nicht warten
- Die einfache Rechnung: heute keine Juniors = morgen keine Seniors = niemand, der repariert, was AI kaputtgemacht hat
Der Weg nach vorn (wenn man ihn will)
- Die Lösung ist nicht kompliziert, aber unangenehm
-
Kernprinzipien
- Akzeptieren, dass Qualität wichtiger ist als Geschwindigkeit: Langsamer veröffentlichen, aber funktionsfähig. Die Kosten für die Behebung von Produktionskatastrophen übersteigen angemessene Entwicklungskosten bei Weitem
- Tatsächlichen Ressourcenverbrauch messen statt ausgelieferter Features: Wenn eine App für dieselbe Funktion zehnmal mehr Ressourcen braucht als im letzten Jahr, ist das kein Fortschritt, sondern Rückschritt
- Effizienz zum Kriterium für Beförderungen machen: Ingenieure belohnen, die den Ressourcenverbrauch senken. Diejenigen sanktionieren, die ihn ohne entsprechenden Mehrwert erhöhen
- Sich nicht hinter Abstraktionen verstecken: Jede Schicht zwischen Code und Hardware kann potenziell 20–30 % Leistung kosten. Deshalb bewusst wählen
- Grundlegende Engineering-Prinzipien wieder lehren: Array-Grenzprüfungen, Speichermanagement und Algorithmuskomplexität sind keine veralteten Konzepte, sondern Grundlagen des Engineerings
Fazit
- Wir erleben derzeit die größte Krise der Softwarequalität der Geschichte
- Calculator leckt 32 GB RAM, AI-Assistenten löschen Produktionsdatenbanken, und Unternehmen geben 364 Milliarden US-Dollar aus, um die Lösung grundlegender Probleme zu vermeiden
- Das ist nicht nachhaltig: Die Physik verhandelt nicht, Energie ist endlich und Hardware hat Grenzen
- Überleben werden nicht die Unternehmen, die die Krise mit Geld überdecken können
- Überleben werden die Unternehmen, die sich daran erinnern, wie Engineering funktioniert
6 Kommentare
Wenn ich mir die Kommentare ansehe, gibt es auch Stimmen im Sinne von, dass es früher ebenfalls so gewesen sei, aber ich halte das für eine Ausrede. Ein Speicherleck ist ein Problem, das man eindeutig erkennen kann, wenn man ein Programm auch nur für die minimal nötige Zeit laufen lässt; dass das nicht gemacht wurde, ist schon ziemlich absurd.
Ich halte das derzeit noch für harmlos. Wenn nun eine Welt kommt, in der KI sogar direkt mit physischen Aktionen und Finanztransaktionen verbunden ist, könnte das tatsächlich zu einer gewaltigen Katastrophe führen.
Ich wünschte, die Stabilität des Explorers in Windows 11 würde etwas verbessert. Es wäre auch schön, wenn das Trennen von Tabs genauso flott wäre wie in Chromium-Browsern..
Hacker-News-Kommentare
Eine meiner Methoden, um heutzutage von KI geschriebene Texte zu erkennen, ist dieses Satzmuster: „Das ist nicht X. Das ist Y.“ In letzter Zeit wird diese Formulierung viel zu oft wiederholt.
Zum Beispiel:
1. „Das ist kein KI-Problem. Qualitätsprobleme haben lange vor dem Erscheinen von ChatGPT begonnen.“
2. „Das ist keine schrittweise Verschlechterung — das ist exponentiell.“
3. „Das ist keine Funktionsanforderung. Das ist ein Memory Leak, den niemand behoben hat.“
4. „Das war nicht komplex. Das war Fehlerbehandlung auf Informatik-Grundkurs-Niveau, die nur niemand implementiert hat.“
5. „Das ist keine Investition, das ist Kapitulation.“
6. „Senior-Entwickler entstehen nicht einfach plötzlich. Sie wachsen aus Junior-Entwicklern heran.“
7. „Die Lösung ist nicht komplex. Nur unbequem.“
Dieses rhetorische Mittel klingt für mich inzwischen wie Kreide auf der Tafel.
Wie auch immer, das ist keine Kritik an der Aussage dieses Artikels, sondern nur mein Gemecker.
Bei Nr. 5 hat mich der Artikel auch komplett erwischt.
Mein KI-Detektor sprang etwas spät an, aber bei der folgenden Passage ging er richtig hoch:
„Die eigentliche Kette von heute: React → Electron → Chromium → Docker → Kubernetes → VM → managed DB → API gateways“
Natürlich kann man sich ein App- oder Service-Backend vorstellen, das solche Technologien kombiniert, aber dass diese „Kette“ tatsächlich genau so zusammenhängt, ergibt nicht wirklich Sinn.
Dass jemand eine Electron-App auf Kubernetes deployt, fühlt sich nicht greifbar an.
Wenn man eine Client-Server-Architektur erklären wollte, hätte man das API-Gateway als Bindeglied zwischen der Electron-App und der Serverseite eingefügt und nicht Electron über Chromium gestellt.
Der Einstieg des Artikels fühlte sich wirklich wie ein „Wut-Blog“ an, aber am Ende wirkte es wie so ein formelhafter Axios-Artikel, der nur Bulletpoints und „clevere“ Überschriften auflistet.
Und weil Überschriften im Stil von „The " so oft auftauchen, riecht das stark nach KI.
Dieses Satzmuster taucht an immer mehr Stellen auf.
Besonders der LinkedIn-Feed ist voll davon, und auch die Kommentare wirken ganz offensichtlich KI-generiert.
Es wird inzwischen auch langsam ermüdend, diese gängigen Formulierungen aktiv zu vermeiden.
Ich benutze keine LLMs.
Ich denke, wir tun gut daran zu akzeptieren, dass wir solchen Formulierungen künftig immer öfter begegnen werden.
Es hat inzwischen kaum noch Sinn, jedes Mal extra darauf hinzuweisen.
Wenn man bedenkt, wie oft es all diese Debatten schon gegeben hat, will ich nicht zu zynisch sein.
Der Wechsel von Assembler zu höheren Programmiersprachen, die Einführung von OOP, Komponentenarchitekturen/COM/CORBA, das Aufkommen des Webbrowsers, die Einführung von Java usw.
2018 war nicht „der Beginn des Niedergangs“, sondern nur ein weiterer Datenpunkt in einer Entwicklung, die schon lange vorher lief.
Wenn man die Entwicklung von der Zeit, als Elite-8-Bit-Spiele auf ein paar KB Tape passten, bis zu MS Flight Simulator 2020 auf mehreren DVDs als Grafik darstellen würde, wäre die Kurve immer noch steigend.
Wo sie abknickt, ist unklar.
Die Softwarequalität war und wird immer dort liegen, wofür Menschen bereit sind zu bezahlen.
Zu der Aussage „Es ist noch nicht klar, wo die Kurve umknickt“: Ich vermute, dieser Punkt kommt dann, wenn Moore's Law endet und wir keine dramatisch schnelleren Maschinen mehr bauen können.
Ich glaube, Software-Updates sind die Ursache des Problems.
Früher funktionierte Software auch nach der Veröffentlichung noch ordentlich, aber irgendwann hat sich das komplett verändert.
Dadurch, dass agile Methoden einen Strohmann in Form des angeblich bisherigen Wasserfall-Modells aufgebaut haben, hat ein Vorgehen nach dem Muster „wir releasen erst, wenn es funktioniert“ technische Schulden in der Praxis praktisch eliminiert.
Ich wünschte, jemand würde daraus wieder eine echte Managementmethode machen.
Anfangs wäre das hart — auch wegen der enormen Menge technischer Schulden in der gesamten Branche —, aber wenn man es einmal durchzieht und wirklich qualitativ hochwertige Software liefert, die man „veröffentlichen und dann vergessen“ kann, würde das die Branche verändern.
Dazu passt übrigens xkcd 2030.
Ein weiterer Grund ist für mich, dass die Tech-Branche die einzige Industrie zu sein scheint, die sich selbst immer noch nicht objektiv betrachten kann.
Es heißt oft, Programmieren sei künstlerisch, aber das gilt in genau demselben Maß auch für Sanitärarbeiten, Elektroverkabelung oder HVAC-Arbeiten.
Man kann daraus zwar persönliche Befriedigung ziehen, aber Unternehmen ist am Ende nur wichtig, dass ein Ergebnis geliefert wird und keine langfristigen Probleme hinterlässt.
Was wir „technische Schulden“ nennen, nennt der Elektriker „Aluminiumverkabelung“ und der Klempner „Weichlöten“.
Letztlich durchläuft jede Branche anfangs eine experimentelle Chaosphase und wird danach standardisiert, mit Lizenzen und formalen Strukturen — deshalb denke ich, dass auch die Softwarebranche irgendwann ein Bereich wird, in dem offiziell lizenziert werden muss.
Wenn man den drastischen Verfall der Softwarequalität nicht spürt, dann interessiert es einen entweder wirklich nicht oder man schaut absichtlich weg.
Der massive Zustrom neuer Entwickler, die Kultur von „Move fast and break things“ und der aktuelle „KI“-Hype zusammen haben die Qualität verschlechtert.
Für Junior-Entwickler gibt es keinen klaren Pfad mehr, um zu Senior-Entwicklern heranzuwachsen.
Die meisten verlassen sich wegen des Marktdrucks auf „KI“-Tools, und dadurch lernen sie kaum noch selbst, wie man debuggt, Probleme löst und ihnen vorbeugt.
Manche nutzen KI gut zum Lernen, aber die meisten lassen sie nur immer wieder laufen.
Ich denke, dieser Trend wird anhalten, bis die Unzufriedenheit der Öffentlichkeit einen neuen Branchenzusammenbruch auslöst.
Vielleicht passiert das gleichzeitig mit dem „Platzen der KI-Blase“, vielleicht auch unabhängig davon.
Dass Softwarequalität im kommerziellen Software-Engineering überhaupt keine Rolle spielt, ist der Grund, warum es sich so anfühlt, als könnten LLMs uns leicht ersetzen.
Bugs sind einfach nicht wichtig.
Früher hätte ich noch eingewandt: „Das wird sich ändern, wenn es kritische Probleme verursacht und dadurch Kunden und Geschäft verloren gehen“, aber selbst nach dem Crowdstrike-Vorfall ging der Alltag einfach weiter.
Weltweit wurden wichtige Dienste lahmgelegt, es entstand ein wirtschaftlicher Schaden von 10 Milliarden Dollar, und trotzdem scheint sich die Wahrnehmung des Marktes nicht grundlegend geändert zu haben.
Wenn die Kunden erst einmal gewonnen sind, sind Bugs nicht besonders wichtig.
Davor haben sie enormen Einfluss.
Das Problem ist nur, dass es für Unternehmen viel zu leicht geworden ist, einen „Moat“ zu bauen, der Nutzer im eigenen Ökosystem einschließt.
Aus Unternehmenssicht ist das gut, aber solche Strukturen bremsen Innovation und machen Nutzer technikmüde und frustriert.
Tatsächlich können LLMs sicherheitsrelevante Bugs — also die wirklich wichtigen Bugs — ziemlich gut finden, deshalb denke ich, dass es künftig fast schon als Fahrlässigkeit gelten könnte, bei Code-Reviews keine LLMs einzusetzen.
Ich musste kürzlich eine nginx-Konfiguration prüfen; das ist nicht mein Hauptgebiet, aber das LLM hat mich auf zwei sicherheitskritische Probleme hingewiesen.
Ich habe auch erfahren, dass eine ältere Release-Version verwendet wurde und dass Pentest-Feedback eingearbeitet werden musste.
LLMs wirken für Analysen wirklich stark, und selbst wenn man ihnen nur ein paar Dateien und bruchstückhafte Informationen gibt, antworten sie in die gewünschte Richtung.
Für die Generierung von ausführbarem Code vertraue ich ihnen noch weniger, aber allein ihre Analysefähigkeit verändert meine Arbeit schon stark.
Bugs sind wichtig.
LLMs werden am Ende nur Werkzeuge sein, die von Menschen genutzt werden, wenn diese Schwachstellen ausnutzen; sie selbst werden uns nicht den Platz wegnehmen.
Seit den 70ern wird an neuronalen Netzen gearbeitet, und es gab zwei große Hürden, um daraus in der Softwareentwicklung echten Nutzen zu ziehen.
Das erste Problem ist erst jetzt gelöst worden — durch mehr Verarbeitungs- und Speicherkapazität sowie die Verbreitung von Open Source.
Das zweite Problem besteht darin, dass die Ausgaben immer noch ziemlich fehlerhaft sind und die Nachbearbeitung beziehungsweise Validierung enormen Aufwand verursacht.
Und dass neuronale Netze bei der Codegenerierung überhaupt konkurrenzfähig geworden sind, liegt paradoxerweise daran, dass die Qualität in der Branche insgesamt so schlecht geworden ist, dass selbst fehlerhafter Code konkurrenzfähig sein kann.
(Siehe auch: xkcd.com/2030)
Ironischerweise stand in einem Artikel, der KI kritisiert, die Passage: „Software, die nur funktioniert, wenn man 364 Milliarden Dollar in Hardware steckt, hat kein Skalierungsproblem, sondern versucht, einen fundamentalen Engineering-Fehler zu kaschieren.“
Wer sich auskennt, weiß das längst.
Er sagt zwar „Ich habe drei Jahre lang Kennzahlen zur Softwarequalität verfolgt“, präsentiert aber keinerlei Daten und zählt stattdessen nur lauter anekdotische Beispiele auf.
Der ganze Artikel hat diesen unbegründeten B-Movie-Copy-Vibe.
Mein persönlicher Eindruck ist, dass 2005 schwache Entwickler routinemäßig mit jQuery, WordPress und PHP Web-Apps am Fließband zusammengebastelt haben.
Die Branchentrends der letzten Jahre haben sich eher in die Richtung entwickelt, mehr auf Codequalität und Struktur zu achten, und heute sind CI/CD, zumindest minimale Tests, Versionsverwaltung mit Git und ordentliches Hosting inzwischen sehr verbreitet.
Vor 20 Jahren war es völlig normal, sich per SSH auf den Server einzuloggen, dort etwas zu ändern und dabei etwas kaputtzumachen.
Dieser Text ist nicht auf KI an sich wütend, sondern auf die Grundidee, mit KI konsistenten Code zu erzeugen.
Ich begrüße den Einsatz von KI-Tools, wenn sie bei Grammatikprüfung oder kreativem Schreiben helfen.
Das ist einfach von Nostalgie verklärt.
Vor 20 Jahren war es keineswegs grundsätzlich besser als heute.
Dass damalige Software keine Gigabytes an RAM fraß, lag schlicht daran, dass es diese RAM-Mengen nicht gab.
Fast jede Software, die ich heute benutze, hat im täglichen Einsatz mindestens zwei Probleme.
Überall gibt es offensichtliche Bugs — Web, Mobile, Konsole —, und sie sind schwer zu diagnostizieren oder zu melden.
Ich verschwende täglich 15 bis 30 Minuten darauf, Bugs zu umgehen.
Heutige Software ist Teil einer Kultur permanenter Veränderung und Updates.
Nach zwei Wochen verlangt eine App schon wieder ein Zwangs-Upgrade.
Selbst Kubuntu LTS spuckt endlose Updates aus.
Rolling-Release-Distributionen — früher nannte man so etwas den unstable branch — werden ganz regulär genutzt.
Ich bin kein Entwickler und kenne die internen Abläufe nicht, aber ich habe den Eindruck, dass Software früher nicht auf diese Weise gebaut oder betrieben wurde.
Es fühlte sich an, als gäbe es mehr „Erwachsene“, die vorsichtiger waren und Probleme vermeiden wollten.
Heute scheint man Probleme einfach hinzunehmen oder zu ignorieren.
(Wobei ich nicht so weit gehen möchte zu sagen, es liege an einer „Unwissenheit, bei der man die Möglichkeit von Problemen gar nicht erkennt“ — aber diese Möglichkeit ist durchaus real.)
Nein, ich bin ziemlich sicher, dass früher schon ein einzelner Bug eine viel größere Sache war und die Qualität insgesamt höher lag.
Es wäre interessant, alte Software objektiv in VMs zu testen.
Heute ist ständiges Updaten möglich, und deshalb ist „schnell releasen und Bugs kontinuierlich beheben“ in jeder Hinsicht vorteilhafter als „langsam und seltener releasen mit weniger Bugs“.
Früher musste Software auf physischen Datenträgern ausgeliefert werden, daher war das Risiko kritischer Bugs viel größer.
Wer sich an die Windows-95-bis-ME-Zeit erinnert, erinnert sich auch daran.
Zufällige Abstürze waren alltäglich, ebenso BSODs und Meldungen wie „hat einen ungültigen Vorgang ausgeführt“, „Gerätefehler“ oder „Windows wurde nach Reparatur der Registry neu gestartet“.
Ctrl+S war der erste Shortcut, den man lernte.
Das Web war pures Chaos mit unterschiedlichen Box-Modellen je Browser, DHTML und CGI auf Shared Hosting.
Ich finde, heute ist es viel einfacher.
Vor 20 Jahren nahm am Telefon noch immer ein Mensch ab, und Probleme konnten gelöst werden.
Natürlich funktionierte damals auch vieles nicht, aber heute hat man oft den Eindruck, dass man es gar nicht erst versucht.
Das ist ein kultureller Wandel insgesamt.
Wir leben heute in einer Ära „probabilistischer Größenordnungen“, in der individuelle Erfahrungen nicht wichtig sind, und KI drängt Computer vom Vorhersehbaren ins Unvorhersehbare — beides geht in dieselbe Richtung.
In Wirths Text „A plea for lean software“ von 1995 beklagt er bereits, dass Dinge, die früher mit ein paar Kilobyte möglich waren, heute Megabytes an RAM benötigen.
„Die heutige Kette: React → Electron → Chromium → Docker → Kubernetes → VM → managed DB → API gateways. Wenn sich da jeweils 20–30 % Overhead aufsummieren, kommt am Ende ein 2- bis 6-facher Performanceverlust heraus.“
Wenn sich das wirklich so aufaddiert, dass am Ende eine Taschenrechner-App 32 GB Speicher leckt, dann nicht, weil es jemand absichtlich so gebaut hätte, sondern weil niemand auf die kumulierten Kosten achtet.
Der MacOS-Rechner verwendet keine dieser Technologien.
Das ist inhaltlich ziemlich ironisch.
Solche Texte habe ich schon oft gelesen; früher konnte ich das gut nachvollziehen, aber inzwischen weiß ich, dass man nicht nur einem Ideal perfekter Software nachjagen muss.
In der Realität sind bei Software immer Trade-offs im Spiel, und meist ist sie ein Mittel zum Zweck für ein Business.
Zwischen „perfekter Software“ und „Software, die 32 GB Speicher leckt“ liegt meiner Meinung nach ein ziemlich breiter Bereich, den wir als Ziel im Blick haben sollten.
Ich mag den Artikel, stimme dem Autor aber darin zu, dass Unternehmen irgendwann an physische Grenzen der Energie stoßen werden.
Ich frage mich allerdings, ob das Energieproblem wirklich der kritische Kipppunkt sein wird.
Schon die Nachrichten darüber, dass große Konzerne in Kernenergie oder den Ausbau der Stromnetze investieren, zeigen ja, dass das Problem erkannt wurde und man sich vorbereitet.
Es gibt keine perfekte Utopie, es gibt immer Trade-offs, und geschäftlicher Erfolg ist wichtig — aber wenn nur noch Profit zählt, wird es problematisch.
Fehlerhafte Software kann mehr Geld verdienen.
Sie liefert schließlich eine gute Begründung dafür, ein Abo-Modell zu verkaufen.
Ich frage mich, wie viel Geld man in der realen Welt wohl mit einem „schlechteren Taschenrechner“ verdient hat.
Wer Anwendungen aus der Zeit von Windows 98 benutzt, merkt schnell, wie instabil damals vieles war.
Vor 20 oder 30 Jahren gab es bei Nutzer-Software mindestens genauso viele Bugs wie heute, und die Sicherheit war insgesamt deutlich schwächer.
Selbst Windows XP konnte sich schon während der Installation infizieren.
Bugs, die heute absolut inakzeptabel wären — Segfaults, Datenverlust —, gehörten damals zum Alltag.
Nur bei der Reaktionsgeschwindigkeit der UI gibt es in letzter Zeit tatsächlich einen spürbaren Rückschritt.
Dass Browser und Electron-Apps selbst mit heutiger RAM-Ausstattung ineffizient sind, stimmt allerdings.
„Windows 98 war auch nicht toll“ ist letztlich nur ein weiterer Beleg dafür, dass Microsofts Codequalität schon immer schlecht war.
Linux war damals trotz eigener Schwächen konstant stabiler.
Microsofts Einfluss auf die Branche war so groß, dass miserable Qualität über 50 Jahre hinweg fast wie ein Standard wirkte.
Auf die Aussage „Windows 98 war ziemlich schlampig“ würde ich nur sagen: Vergleiche mal ein vollständig gepatchtes Windows 7 mit Windows 11.
Es gibt nicht nur genau diese zwei Vergleichspunkte.
Man muss auch den allgemeinen Trend seit den 2020er Jahren betrachten.
Und bei der Behauptung „nur die UI-Reaktionsgeschwindigkeit ist etwas schlechter geworden“ sieht die Realität eher nach einer Verschlechterung um den Faktor 10 bis 100 in allen Komponenten aus.
Man muss sich nur MS Teams anschauen.
Das Ideal von hochwertigem Code finde ich gut, aber beim Thema Energieeffizienz stimme ich nicht wirklich zu.
Der Stromverbrauch von Rechenzentren ist im Vergleich zum gesamten globalen Energiehaushalt verschwindend gering.
Verglichen mit Solarenergie, Ölverbrauch oder globalem BIP steht die digitale Industrie in Sachen Energieeffizienz im Verhältnis zu anderen Branchen eher gut da.
Wenn man Ressourcen auf CO2-Ausstoß und Erderwärmung konzentrieren will, sollte man eher andere Industrien wie Verbrennungsmotoren in den Blick nehmen.
Möglicherweise ist sogar der Energieverbrauch des Lebensstils von Softwareingenieuren — Pendeln, Geschäftsreisen, allgemeine Lebensführung — größer.
2025 ist erneuerbare Energie ohnehin schon viel günstiger geworden, daher gibt es meiner Meinung nach andere Themen, die wirklich wichtig sind.
Ich habe kürzlich auf einem Flughafen furchtbare Software erlebt.
12 von 15 automatischen Passkontrollschleusen fielen mit Fehlermeldungen aus.
Immer mehr Schleusen gingen kaputt, bis das Personal anfangen musste, manuell zu helfen.
Ich frage mich, wie so ein offensichtlich unreifes System überhaupt eingeführt werden kann.
Und ich frage mich, warum die Leute vor Ort bei solchen Problemen die Geräte nicht einmal neu starten dürfen.
Verletzt wurde niemand, aber das eigentliche Problem scheint mir zu sein, dass Softwarelizenzverträge den Anbietern erlauben, sich bei Qualitätsproblemen aus der Verantwortung zu ziehen.
In jeder anderen Branche wäre so etwas unakzeptabel.
Unreife Software wird deshalb ausgeliefert, weil der heutige Mindeststandard in der Branche offenbar lautet: „Solange wir nicht verklagt werden und der Kunde das Produkt nicht klar ablehnt, ist es okay.“
Alles wird hektisch auf den Markt gebracht, und die Entscheidung zur Auslieferung hängt nur davon ab, ob das Unternehmen sein investiertes Geld wieder hereinholen kann.
Wenn die erwartete Rendite stimmt, wird eben geliefert, auch wenn die Qualität nicht ausreicht.
Dann warst du also auch im Terminal 2 des Flughafens Heathrow — ich musste lachen, weil deine Erfahrung meiner so ähnlich ist.
> Wenn man bedenkt, dass all diese Debatten schon seit Ewigkeiten unzählige Male geführt wurden, möchte ich nicht allzu skeptisch sein.
Der Wechsel von Assembler zu höheren Programmiersprachen, die Einführung von OOP, Komponentenarchitekturen/COM/CORBA, das Aufkommen des Webbrowsers, die Einführung von Java usw. – 2018 war nicht der „Beginn des Niedergangs“, sondern nur einer von vielen Datenpunkten, die sich seit Langem aneinanderreihen.
Wenn ich einmal widersprechen darf: Die Person, die den Kommentar geschrieben hat, scheint die im eigentlichen Beitrag beschriebene Problemdefinition nicht verstanden zu haben. Der oben erwähnte Wechsel zu High-Level-Sprachen hat überhaupt nichts mit den durch KI generierten Schwachstellen im Code oder mit einer Struktur zu tun, in der keine Senior Engineers hervorgebracht werden können. Vielmehr hat der Kommentator mit seinem eigenen Kommentar am Ende selbst die Probleme des Haupttexts bestätigt. Es geht um die Bedeutung von Engineering, aber offenbar mag die Person anspruchsvolles Engineering nicht, will es auch nicht lernen und bringt deshalb zu viele Ausreden vor. Viel zu viel Gerede.
> Ich bin kein Entwickler, also kenne ich die internen Umstände nicht, aber ich habe das Gefühl, dass Software früher nicht auf diese Weise entwickelt oder betrieben wurde. Es wirkte, als gäbe es mehr „Erwachsene“, die vorsichtiger darauf bedacht waren, Probleme zu vermeiden.
Es scheint, als wäre er nicht einmal Entwickler..