- Viel mehr Systeme, als viele Menschen sich vorstellen, können auf alter Hardware problemlos betrieben werden
- Wenn echte Software-Optimierung erfolgt, ist es sehr wahrscheinlich, dass sich diese Effizienz erreichen lässt
- Die Marktpreissignale knapper Rechenressourcen schaffen Anreize für Software-Effizienz
- Es besteht die Notwendigkeit, bestehende interpreterbasierte Microservices von Produkten auf eine monolithische Architektur mit nativem Code umzustellen
- Andererseits würden ohne sehr günstige und skalierbare Rechenressourcen innovative neue Produktentwicklungen vermutlich deutlich seltener stattfinden
1 Kommentare
Hacker-News-Kommentare
Man kann argumentieren, dass sich auf dem Markt fehlerhafte und ineffiziente Software genauso gut verkauft wie perfekte Software; von beiden setzt sich die durch, die am billigsten herzustellen ist. Das ähnelt der Geschichte vom „Lemons Market“: Der Markt handelt alle Produkte, als wären sie hochwertig, tatsächlich wird aber Qualität geopfert, um Kosten zu senken. Käufer können vor dem Kauf nicht zwischen hoher und niedriger Qualität unterscheiden, wodurch die Nachfrage nach beiden künstlich ähnlich wird. Das ist Informationsasymmetrie. Dieses Phänomen ist bereits Realität und wird es bei AI zunehmend ebenfalls. Nutzer können nicht zwischen ausgefeilten Machine-Learning-Anwendungen und einer Waschmaschine unterscheiden, auf die nur das Label „AI“ geklebt wurde. Das AI-Label erzeugt für sich genommen einen Preisaufschlag, also zahlen Nutzer zu viel für die Waschmaschine. Es ist im Kern dasselbe, wenn Käufer für miserable Software zahlen, weil sie glauben, sie sei „von Experten entworfen und geschrieben“ worden. Fast alle Software wird auf IC1-3-Niveau geschrieben, und QA ist in den meisten Unternehmen die einzige Kennzahl für Qualitätsverbesserung, oft von einer einzelnen Person getragen. Manchmal erwartet man Verbesserungen von Praktikanten, die den „LGTM“-Spruch aufsagen, aber in Wirklichkeit ist selbst das selten.
Ich habe versucht, ein Software-Startup aufzubauen, das sich über Qualität differenziert. Ich war überzeugt, dass die Leute ein besseres Produkt erkennen und es sich dann durchsetzen würde, aber in der Praxis war das nicht so. Wir sind gewachsen, aber zu langsam, und das Geld war aufgebraucht, bevor wir profitabel wurden. Meine Erkenntnis: Niedrige Kosten und damit niedrige Qualität werden in wettbewerbsintensiven Märkten zum Wettbewerbsvorteil. Das hatte ich seit dem Studium gehört, aber erst durch diese Erfahrung wirklich verinnerlicht. Deshalb wird auf Märkten am Ende alles mittelmäßig, und deshalb verschlechtert sich selbst hohe Qualität, je populärer etwas wird. Je größer ein Produkt wird, desto stärker wird der Druck, Kosten zu senken. Menschen wollen billig kaufen, also spart jemand an Kosten und damit an Qualität, um billiger anbieten zu können. Unternehmen zahlen nur das Nötigste, um zu überleben und Gewinn zu machen. Natürlich gibt es manchmal Ausnahmen, aber am Ende läuft es auf schrittweise Kostensenkung hinaus. Es gibt dafür vermutlich einen Namen; es ist etwas anders als der Lemons Market. Der Markt bricht nicht zusammen, aber es entsteht überall eine stabile Mittelmäßigkeit.
Ich widerspreche der Sicht, dass der „Markt“ alle Produkte als hochwertig verkauft. Entscheidend ist, was hier mit „hochwertig“ gemeint ist. Es klingt so, als bedeute schlechte Performance automatisch niedrige Qualität, aber tatsächlich gibt es für Apps wie Teams, Slack oder Jira, die als langsam gelten, Konkurrenzprodukte mit deutlich besserer Performance. Wenn man Nutzer aber vor die Wahl stellt, statt Slack lieber Weechat mit Terminal-UI, ohne Videochat und ohne Emojis zu verwenden, würden die meisten Letzteres als das minderwertigere Produkt ansehen. Performance ist nur ein Feature unter vielen. Der frühe Erfolg von Chrome beruhte zum Beispiel auf seiner Geschwindigkeit, und Python-Entwickler wechseln wegen Performanceverbesserungen zu uv/ruff. Aber wenn Slack statt in 5 Sekunden in 10 ms starten würde, wäre das den meisten Nutzern egal.
Ich stimme nicht zu, dass ineffiziente Software auf eine Lemons-Markt-Struktur zurückgeht. Das gilt nur bei Informationsasymmetrie. In den meisten Fällen stören sich Menschen nicht an ein paar Bugs und wollen lieber einen niedrigeren Preis. Wenn man sehr gründliche QA und mehrstufige Code-Prüfprozesse durchläuft, sieht man den Unterschied sofort am Preis. Ich habe einmal Software für einen kleinen Buchladen gebaut; ich habe sie schnell entwickelt und nicht viel dafür verlangt. Sie war nicht perfekt, aber ich habe Probleme sofort behoben, und der Kunde war zufrieden, weil es für ihn ein gutes Geschäft war.
Ich habe in Großunternehmen schreckliche HR-, Spesen-, Zeiterfassungs- und Versicherungsportale benutzt. Sie waren so schlecht, dass ich mich fragte, ob die Person, die dafür bezahlt hat, das Produkt jemals selbst verwendet hat. Wenn ein Team einem Kunden ein Produkt voller Bugs und UI-Albträume vorsetzen würde, gäbe es sofort eine Rüge, eine Degradierung oder sogar eine Kündigung.
Das Wesentliche daran, dass der Markt „fehlerhafte, ineffiziente Software“ gut kauft, ist, dass der Markt <i>Support</i> kauft. Das gilt auch für Google oder Firmen mit wenig menschlichem Support. „Support“ zeigt sich in vielen Formen — Dokumentation, Videos, Blog-Informationen, hilfreiche Menschen, Unterstützung für meine Umgebung (Betriebssystem, Browser usw.), Unterstützung für die Aufgaben, die ich erledigen will, und so weiter. Der wichtigste Faktor dafür, dass selbst das schlimmste ERP überlebt, sind am Ende echte Menschen. Ob Support vorhanden ist oder nicht, entscheidet über die Überlebenslinie eines Produkts. Für kleine Teams ist es klüger, den Bedarf an Support zu reduzieren und Support in einer anderen Dimension bereitzustellen, wenn sie im Wettbewerb bestehen wollen. Der einfachste Weg ist, Menschen hinzuzufügen. Und man muss die eigenen Stärken richtig kommunizieren. Verschiedene Arten von Support werden unterschiedlich bewertet; wie bei Open-Source-Code vs. proprietärem Code bevorzugen viele proprietäre Lösungen, wenn sie dort mehr Support bekommen.
Einer der Hauptgründe, warum ich gern bei Costco einkaufe, ist, dass sie in der Regel keinen völligen Schrott verkaufen. Ihr Filter deckt sich nicht immer mit meinen Maßstäben, aber es ist immerhin ein sinnvoller Qualitätsfilter.
Selbst wenn Nutzer Entscheidungen auf Basis von Softwarequalität und Performance treffen könnten, zeigt meine Liste geöffneter Apps, dass sich keine davon allein deshalb ersetzen ließe, weil etwas anderes performanter ist. Docker, iterm2 oder WhatsApp nutze ich jeweils aus ganz konkreten Gründen. Selbst wenn es die schnellste Lösung gäbe, könnte ich nicht einfach wechseln. Dass es überhaupt Software gibt, die meine Anforderungen von Anfang an erfüllt, ist ein wichtigerer Faktor als Performance.
99 % der Software werden geschrieben, ohne Performance überhaupt zu berücksichtigen. Selbst auf HN gilt Performanceverbesserung oft als Tabu. Sogar Ingenieuren auf L4/5-Niveau fehlt häufig jedes Gefühl für Performance. Auch aus Business-Sicht kümmert man sich nicht um Effizienz, bis die vorhandene Hardware die Software nicht mehr ausführen kann. Und selbst dann versucht man zuerst, das Problem durch zusätzliche Hardware zu lösen.
Die heutige Marktstruktur sorgt dafür, dass fehlerhafte und ineffiziente Software dominiert, weil man jederzeit Hardware kaufen kann, auf der sie läuft. Software bläht sich auf, um die Rechenleistung der Hardware auszufüllen — das ist das Gesetz „What Andy gives, Bill takes away“. Deshalb gibt es keinen Anreiz, schlanke, hochwertige Software zu bauen. Wenn aber eine Welt käme, in der modernste Chips nicht mehr verfügbar sind — etwa durch eine geopolitische Krise oder die Zerstörung großer Fabriken —, dann bekäme ressourcensparende Software einen enormen wirtschaftlichen Wert. Aufgeblähte Software ließe sich dann schlicht nicht mehr ausführen. Carmack sagt, dass es in so einer Situation genügend Spielraum für Optimierung gibt und man Software am Ende irgendwie auch auf Chips aus vergangenen Zeiten zum Laufen bringen könnte.
Gut entworfene Software lässt sich leicht ersetzen. Ein Haufen fehlerhafter Spaghetti-Code dagegen bleibt ewig, weil niemand ihn anfassen will. Rein evolutionär betrachtet bedeutet das, dass schlechte Software am Ende dominiert.
Der Gebrauchtwagenmarkt ist ein Lemons Market, weil man gut gepflegte Autos schwer von Autos kurz vor dem Defekt unterscheiden kann. Auf den Neuwagenmarkt trifft das nicht zu, weil er streng reguliert ist. Software ist immer neu. So wie sich die Qualität von Autos über Jahrzehnte verbessert hat, könnte man auch die Qualität von Software erhöhen: Verkauf nur, wenn bestimmte Standards erfüllt sind; Rückrufe bei schweren Bugs; Strafen für den absichtlichen Verkauf mangelhafter Produkte. So funktionieren alle anderen Industrien.
Durch Web-2.0-„Perpetual Beta“ und das SaaS-Modell hat sich auch die Geduld der Nutzer verändert. Microsoft hat über Generationen hinweg das Bewusstsein geprägt, dass „Software eben kaputt ist“. Da sich alle an schlechte Software gewöhnt haben, erkennen sie den Wert guter Software kaum noch.
Ich habe tatsächlich so eine Waschmaschine mit AI-Aufkleber gekauft. Das Marketing fand ich lächerlich, aber der Preis war vernünftig, also habe ich sie gekauft.
Vermutlich geht es nur um Sicherheitslücken. Wenn Excel oder Photoshop voller Performanceprobleme und anderer Bugs wären, würden die Leute sie schnell nicht mehr benutzen. Sicherheit dagegen bemerkt der Nutzer erst, wenn etwas passiert, und selbst nach einem Hack kennt er oft die Ursache nicht. Für Entwickler gibt es dafür keinen Anreiz. Bei Performance gilt außerdem: Ab einem gewissen Punkt sinkt die Bereitschaft, weitere Ressourcen in Optimierung zu stecken. Das ist das Gesetz des abnehmenden Ertrags.
Auch wenn Nutzer nicht zwischen ausgefeilter AI und einer bloßen „AI-Waschmaschine“ unterscheiden können, könnte gute AI Nutzern helfen, diese Informationsasymmetrie selbst zu überwinden. Wenn es nur eine Methode gäbe, gute AI auszuwählen, ließe sich das Problem lösen.
Ich glaube nicht, dass die „billigste Software“ automatisch billig ist. Auf Startup-Niveau ist hingeschluderte Software vielleicht günstiger, aber in großem Maßstab kostet sie am Ende oft mehr. Fluggesellschaften sparen sogar an einer einzelnen Olive, um Kosten zu senken, deshalb frage ich mich, warum es bei Entwicklern angeblich nicht effizient sein soll, sie optimieren zu lassen. Wir fügen ständig neue Features hinzu, aber Nutzer spüren am Ende nur, dass jede Aktualisierung langsamer wird. Wenn etwas dagegen schneller wird, jubeln sie sofort. Ingenieure verhalten sich dabei oft wie MBAs und wiederholen nur, das habe „keinen Wert“. Aber der „Wert“ von Bugfixes ist hochgradig subjektiv. Die Aufgabe von Ingenieuren ist es, Bugs zu beheben. Marken sind ebenfalls wichtig, aber die großen Marken von heute ignorieren ihren Markenwert. Vermutlich, weil Verbraucher ohnehin kaum wechseln — und wenn sie doch wechseln, bekommen sie nur neue UIs und mehr Dinge, die sie neu lernen müssen. Sogar Apple ist nicht mehr intuitiv.
Die heutige Welt könnte zwar noch auf alter Hardware laufen, aber CPU und Hardware werden ohnehin immer schneller, also gibt es keinen echten Grund, Code effizienter zu machen.
Das Problem der Informationsasymmetrie lässt sich bei FOSS oder proprietären „Shared Source“-Produkten überwinden. Wenn man den Code direkt ansieht, kann man beurteilen, ob die Gesamtqualität stimmt. Selbst wenn man keine konkreten Bugs findet, lässt sich an Funktionslängen, Kommentaren, Benennungen usw. erkennen, ob eine gewissenhafte Entwicklungskultur existiert. Wenn man wirklich hinschaut, schafft ein teures proprietäres Produkt mit chaotischem DB-Schema kein Vertrauen.
Schlechte Software ist langfristig in der Herstellung und Wartung teurer.
Genau deshalb spielt die Marke die Rolle des Wächters über Qualität.
So wie der Verkauf giftiger, abgelaufener oder suchtfördernder Zusätze in Lebensmitteln gesetzlich verboten ist, sollte es auch für Software Regulierung geben. Aber bis zur Einführung der GDPR war Regulierung fast bedeutungslos, und auch heute sind Verstöße alltäglich.
Seit 1980 ist die Rechenleistung um etwa das Tausendfache gestiegen. Wenn man annimmt, dass dynamische Array-Grenzprüfungen 5 % Performance kosten — in Wirklichkeit ist es deutlich weniger —, dann hätten wir mit aktivierten Checks immer noch Computer, die 950-mal schneller sind. Wenn man ins Jahr 1980 zurückginge und zwischen „einem 950-mal schnelleren Computer mit weniger Bugs und leichterem Debugging“ und „einem einfach 1000-mal schnelleren Computer, der immer noch voller Bugs ist und sich schwerer debuggen lässt“ wählen müsste, würden die meisten den 950er nehmen. Wir haben uns aber am Ende für die 1000 entschieden. Ich persönlich denke, dass die 1000Xer die Situation ruiniert haben.
Aber diese 1000-fache Leistung wird nicht durch Bounds Checking aufgefressen, sondern durch endlose Abstraktionen und Ineffizienz verschwendet.
Ich habe einmal einen Anbieter gezwungen, seine langsame und fehlerhafte Software auf einer Sparc 20 laufen zu lassen. Das Ergebnis war, dass sie die Software optimiert haben, und genau das schuf die Grundlage dafür, dass die Firma am Markt erfolgreich wurde. Optimierung ist ein Wettbewerbsvorteil.
Das gilt nur für die Zeit seit 1980. In einem aktuellen Video wurde es so zusammengefasst: „Heutige Computer sind nicht viel schneller als Computer vor 20 Jahren, und das merkt man nur, wenn speziell optimiert wurde.“ Der Autor ignorierte zwar Dinge wie Compiler-Optimierung, aber der tatsächliche Performancegewinn war geringer als gedacht; angeblich hat er sich in 15 Jahren nur verdoppelt.
Es hieß, Array-Bounds-Checks kosteten nur 5 %, aber nicht alle Algorithmen sind so simpel. Je nach Anzahl der Operationen kann allein das Einführen solcher Checks die Kosten um das Drei- bis Vierfache erhöhen. Für bestimmte Einsatzbereiche verliert eine Sprache ihre Wettbewerbsfähigkeit, wenn man solche Checks zwingend macht. In den meisten Fällen spielt das keine Rolle, aber eine Trennung in sicheren und normalen Modus wäre sinnvoll.
Wenn man nur Bounds Checking betrachtet, sind die Kosten eher gering, aber der Overhead sicherer Sprachen insgesamt ist deutlich größer. Bei GC-Sprachen kann sich der Speicherverbrauch um ein Mehrfaches erhöhen.
Man darf das Gesetz der großen Zahlen nicht vergessen. Ein Performanceverlust von 5 % in einem einzelnen System ist vielleicht nicht dramatisch, aber wenn sich 5 % Verlust über die gesamte weltweite Computing-Infrastruktur aufsummieren, hat das enorme Auswirkungen.
Ich stimme der menschlichen Neigung zu kurzfristigem Nutzen zu, aber dynamische Grenzprüfungen lösen Sicherheitsprobleme nicht an sich. Eine endgültige Lösung gibt es noch nicht.
Der grundlegende Grund dafür, warum wir heute hier stehen, ist, dass wir an den Browser gefesselt sind.
Die erste Antwort ist im Grunde die richtige. Schon die Tatsache, dass C weiterhin weit verbreitet ist, zeigt, dass das eigentliche Problem in einer ineffizienten Struktur weiter unten im Stack liegt.
Diese „5 %“ wirken fragwürdig. Ich traue der Grundlage dieser Schätzung nicht. Wenn bei jedem Einfügen in ein Array geprüft wird, würde mich nicht wundern, wenn sich die Kosten real eher als verdoppeln.
Die meisten heutigen Programmiersprachen unterstützen Array-Bounds-Checks standardmäßig.
Das erinnert mich an die Anfangszeit von Node.js. Damals war der große Vorteil, Client- und Server-Code zu verbinden, aber inzwischen ist es ein Sicherheitsalbtraum. Deshalb haben auch minimalistische Sprachen mit kleiner Codebasis Vorteile.
Hätten wir nur früher verstanden, dass ein einzelner String Daten im Gigabyte-Bereich enthalten kann, wären nullterminierte Strings verschwunden und allen wäre viel Leid erspart geblieben.
Die 1000Xer, die tatsächlich Freude an einem 1000-mal schnelleren Produkt haben, sind eher eine kleine Minderheit. Für normale Nutzer bleibt Desktop-Software weiterhin langsam.
In Wirklichkeit ist alles eher 100.000-mal schneller geworden: allein der Takt 1000-fach, die Kernzahl 10-fach, die Instruktionen selbst durch Dinge wie AVX noch einmal 10-fach — architektonisch also 1 bis 2 Millionen Mal schneller. Und trotzdem merkt man davon im Alltag nichts.
Jemand zitierte Robert Barton, der solche Leute als „hohe Priester eines niederträchtigen Kults“ bezeichnete.
Seit 1980 stimmt das, aber seit 2005 betrachtet sind es eher rund 5x Verbesserung.
Der Takt ist 2000-fach, mit SIMD usw. kommt noch etwa 80-fache IPC dazu, multipliziert mit den Kernen landet man bei 1 bis 2 Millionen Mal schneller. Trotzdem denken die meisten Autoren von Programmen einfach: „Wenn es läuft, dann läuft es eben mit dieser Geschwindigkeit.“ Nur eine sehr kleine Minderheit denkt überhaupt über Optimierung nach, auch unter HN-Nutzern.
Im Rückblick hätte man einen 1-GHz-CPU-Stand von 2001 als Basis für Standardsoftware festschreiben sollen. Auch die AI-Erfahrung war ziemlich enttäuschend. Ich hatte erwartet, dass LLMs Dinge wie Sprachumwandlung oder Code-Optimierung gut beherrschen würden, aber so ist es nicht. Ich habe AI sogar einmal Unix-
sed-Code in eine JVM-Sprache portieren lassen; über einfache Grundlagen hinaus scheiterte sie komplett am mittleren Niveau. Letztlich dient dieser ganze Trend nicht der Verbesserung der Softwarequalität, sondern der Reduktion von Arbeitsplätzen. AI wird künftig noch mehr schlechte Software hervorbringen.Das ist genau JavaScript — und die Zukunft der Nutzer.
Durch die Arbeit bei Google (und Facebook) habe ich gemerkt, wie billig Hardware ist und wie oft Code-Optimierung praktisch keinen Wert hat. Schon vor mehr als zehn Jahren war Ressourcenmanagement im Rechenzentrum bei Google Pflicht, und jedes Projekt hatte ein Budget. CPU, HDD, Flash usw. wurden gegeneinander verrechnet, um relative Kosten zu bestimmen. Selbst wenn Flash 20-mal teurer war als HDD, war Flash unter Berücksichtigung realer Bottlenecks oft trotzdem billiger. Solche Ressourcen wurden sogar gegen die Arbeitszeit von Software Engineers umgerechnet (1 SWE = 1 Personenjahr). Wenn man durch Optimierung nicht mehr als 5000 CPU-Kerne einsparen konnte, war es unterm Strich ein Verlust. Optimierung lohnte sich nur bei sehr großen Projekten; ansonsten war sie sinnlos, weil der Code ohnehin bald ersetzt wurde. Außerdem ist aus Web-Usability-Sicht das Maus-Interface sehr ineffizient, während textbasierte Terminals vor 30 bis 40 Jahren viel effizienter waren. Ich hatte gehofft, das Web würde standardisiert und damit den Weg in die nächste Phase ebnen, aber das ist nicht passiert. Stattdessen erscheint weiterhin jede Woche ein neues Framework, und selbst dieselbe Scrollbar wird hardwareinkompatibel neu implementiert. Ich weiß nicht, was die Lösung dafür ist.
Meiner Ansicht nach gilt diese Einschätzung nur für Unternehmen mit hohen Engineering-Kosten, großen Margen und vielen Projekten. Sobald auch nur ein wenig Geld übrig bleibt, ist es besser, Ingenieure auf Optimierung anzusetzen. In der Praxis ahmen Firmen einfach Google nach und treffen Entscheidungen unabhängig von wirtschaftlicher Logik, was viele Probleme erklärt.
Ich war ebenfalls bei Google, und dort sprach man zwar oft über die Optimierung der CPU-Nutzung pro Maschine, tatsächlich wurden aber zwei Dinge ganz besonders betont: Latenz und die Gesamtauslastung der Server. Beides waren wichtige KPIs höherer Organisationseinheiten, in die enorme Engineering-Ressourcen flossen. Je mehr Maschinen man hat, desto weniger will man sie untätig herumstehen lassen, und latenzsensitive Geschäfte versuchen selbst einzelne Millisekunden einzusparen.
Google kann so denken, weil dort die Kosten pro Kern groß genug sind. Für die meisten normalen Unternehmen gilt das überhaupt nicht; das funktioniert nur in Größenordnungen wie bei Facebook, Google oder Netflix.
Dass Google bessere Kompressionsverfahren und binäre Serialisierungsformate entwickelt hat, diente ebenfalls der Verbesserung der eigenen Rentabilität.
Als ich die Überschrift des Artikels sah, dachte ich, Carmack würde Softwareoptimierung für schwache Hardware kritisieren. Tatsächlich ist das nicht der Fall; er spricht über ein Gedankenexperiment, in dem der Hardwarefortschritt stoppt, und kommt am Ende zu dem Schluss: „Ohne billiges und gut skalierbares Computing gibt es weniger innovative Produkte.“
Das hängt mit dem Thread von gestern zusammen.
Zu der Schlussfolgerung „Ohne billiges und skalierbares Computing nimmt Innovation ab“: Tatsächlich haben wir seit dem Smartphone fast keine Innovation mehr gesehen, und weil Kapital nur noch auf Hardwarefortschritt setzt, unterscheiden sich neue Produkte im Kern kaum noch von bestehenden.
Persönlich stimme ich dem nicht zu. Selbst wenn man die Feature-Entwicklung vorübergehend anhält, wird Innovation nach ausreichender Vorbereitung zurückkehren. Es mag einen Rückgang geben, aber keinen dauerhaften.
Der Kernpunkt ist, dass „Bloat“ nicht bloß Verschwendung ist, sondern eine wirtschaftlich motivierte Steigerung der Entwicklungsgeschwindigkeit. Wenn man mit weniger komplexen Sprachen produktiver wird, kann man mehr Leute einstellen und Kosten senken.
Wenn man die Lebensdauer von Hardware um 5 oder 10 Jahre über die geplante Obsoleszenz hinaus verlängern könnte, ließen sich enorme Mengen an Elektroschrott, seltenen Mineralien und Treibhausgasemissionen einsparen. Doch der Softwaremarkt trägt die Kosten dieser externen Effekte nicht. Nach dem Release zu testen, zu korrigieren und zu iterieren ist viel billiger als langfristige Planung. Teile der Spieleindustrie haben eine Formel aus hoher Performance und Umsatz gefunden, aber das ist nicht weit verbreitet. Enterprise- und Consumer-Software achtet bei Performance meist nur auf die Mindestanforderungen, die Nutzer gerade noch tolerieren. Durch die ständige Ergänzung neuer Features und Änderungen ist es schwer, sich um Performance zu kümmern, und in Budgets sind Fehlerraten ohnehin eingepreist. Anders als bei einem eher „fertigen“ Release-Modell sind Komplexität und Änderungsrisiko hoch.
Seit mehr als zehn Jahren betreiben wir die komplette Matching Engine einer Börse auf einem einzelnen Thread. Zumindest bei serialisierter Handelsverarbeitung ist die Rechenleistung nicht so schnell gewachsen. Wenn man nicht bei mehreren Millionen TPS liegt, muss man gar nicht auf Cluster skalieren. Stattdessen kann man das Design vereinfachen und alles auf einer einzigen Maschine ausführen.
Das ist wirklich frustrierend. Viele Systemarchitekten haben Systeme nur komplizierter gemacht, um ihre eigene Handschrift zu hinterlassen, und dadurch bloß neue Probleme erzeugt. Das ursprüngliche Design hätte die meisten Anforderungen erfüllt, und mit heutiger lokaler Rechenleistung wäre eine einzelne Maschine völlig ausreichend.
Ich frage mich, warum Order-Matching nicht parallelisiert werden kann. Könnte man nicht eine Art logarithmische Reduktion ähnlich wie beim Sortieren anwenden? Oder liegt es daran, dass im Matching-Prozess außer einfachem Sortieren gar nicht viel weitere Berechnung steckt?
Für einfache Verarbeitung reicht ein einzelner Thread, aber wenn jede Transaktion komplexe Berechnungen erfordert, geht das nicht. Mir fehlt allerdings das Domänenwissen, um einzuschätzen, was in der Praxis überhaupt so komplex wäre.
Wenn sich Entwicklerwerkzeuge weiterentwickelt hätten, hätte man wie früher mit RAD leicht vollständig native GUIs bauen können; stattdessen dominiert heute Electron. Auf dem Rechner sind mehrere Webbrowser installiert, jeder als Chromium-basierte Variante.
Am Ende ist es ein ökonomisches Problem der Ressourcenallokation: Soll man Entwickler Zeit in die Softwareoptimierung investieren lassen oder in neue Features? Wenn Letzteres mehr Gewinn bringt, wird man das tun. Wenn Optimierung wichtiger ist, handelt man entsprechend.
Ich stimme zu, dass es ein ökonomisches Thema ist, aber im Kern ist es ein Fall, in dem Softwareunternehmen negative externe Effekte auf die gesamte Gesellschaft abwälzen. Zusätzlicher Energieverbrauch, Verschwendung und mehr Elektroschrott werden nicht berücksichtigt.
Technische und finanzielle Schulden werden auf andere abgewälzt, und das System produziert nur noch mehr Müll. Oft lohnt sich Optimierung tatsächlich nicht, aber die Gewohnheit, einfach weitere Server hinzuzufügen, ist trotzdem bedauerlich.
Dass „mehr Features wichtiger sind“, hängt vom Einzelfall ab. Ich nutze die meisten neuen Funktionen in aktuellem macOS, Windows oder Android nicht; mir sind eine effiziente Umgebung und Sicherheit wichtiger. Auch bei Designsoftware wünsche ich mir eher Effizienzverbesserungen als neue Features. Manchmal hätte ich lieber Illustrator oder Photoshop von vor zehn Jahren. Bei Musiksoftware können neue Funktionen zwar echte Bedürfnisse erfüllen, aber sobald sie die Effizienz verschlechtern, stößt mich das ab. Als Code-Editor reicht mir VSCode; ich wünschte nur, es wäre schneller und leichter.
In meinem Leben ist Effizienz sehr wichtig. Wenn ich zum Beispiel in die Küche gehe, um etwas zu holen, nehme ich immer Müll oder Geschirr mit zurück, damit ich nicht zweimal laufen muss. Bei Software ist es ähnlich. Aber zwischen „teure Engineering-Zeit für Optimierung einsetzen“ und „mehr RAM/Ressourcen hinzufügen“ ist Letzteres fast immer billiger. Erst wenn das Problem groß genug wird, lohnt sich Optimierung. Der Markt entscheidet am Ende, welche Wahl sinnvoller ist. Wenn der Nutzen zusätzlicher Hardware sinkt, wird man auf Optimierung umschwenken. Das ist bisher noch nicht passiert, weil Moores Gesetz seine Grenze noch nicht erreicht hat.
Letztlich ist es eine Frage der Nachfrage. Wenn Verbraucher schnellere Software wichtig fänden, würden sie dafür auch mehr bezahlen, aber in der Praxis wählen sie oft lieber das billigere Produkt, selbst wenn die Performance schlechter ist.
Genau das ist die Definition von „enshitification“.
Electron-Apps sorgen zwar oft für Frust wegen ihrer Performance, waren aber die entscheidende Innovation, die es mir möglich gemacht hat, eine Arbeitsumgebung auf einem Linux-Laptop auszuhalten. Zum Beispiel kann ich ohne Installation problemlos an Teams-Meetings teilnehmen. So sehr sich alle nach der Code-Optimierung von Winamp zurücksehnen mögen — die Zugänglichkeit von Electron-Apps ist im Alltag bequem.
Beim Spielen von Balatro ist mir kürzlich aufgefallen: Es ist immer noch ein Spiel, das nur einfache Berechnungen und schlichte Grafik verarbeitet, und doch steigen die Mindestanforderungen weiter. Es wirkt wie ein Spiel, das schon auf Hardware der 90er Jahre (Pentium II + 3dfx) laufen müsste, verlangt aber Spezifikationen, die praktisch erst aktuelle Laptops problemlos erfüllen. Das ist erstaunlich überzogen.