- Wenn Software-Optimierung wirklich Priorität hätte, könnten weit mehr Systeme als erwartet auch auf älterer Hardware laufen
- Wenn bei knappen Computing-Ressourcen Marktpreissignale wirken, steigt der Druck, effizientere Software zu entwickeln
- Ein Beispiel dafür ist, in interpretierten Sprachen und auf Microservices basierende Produkte wieder in monolithische native Codebasen umzubauen
- Ohne extrem günstiges, hochskalierbares Computing könnte es jedoch deutlich seltener werden, innovative neue Produkte zu erproben und auf den Markt zu bringen
- Leistungsoptimierung allein reicht nicht aus; günstiges und skalierbares Computing entscheidet über die Häufigkeit von Produktexperimenten und Releases
Gedankenexperiment mit Optimierung als Priorität
- Wenn Software-Optimierung wirklich Priorität hätte, könnten weit mehr Systeme als erwartet auch auf alter Hardware betrieben werden
- Wenn Preissignale bei knappen Computing-Ressourcen stark wirken, würde der Markt effizientere Software verlangen
Mögliche Umsetzungswege und Einschränkungen
- Ein Beispiel ist, in interpretierten Sprachen und als Microservices-basierte Produkte entwickelte Systeme wieder in monolithische native Codebasen umzubauen
- Ohne extrem günstiges, hochskalierbares Computing könnten innovative neue Produkte jedoch deutlich seltener werden
1 Kommentare
Hacker-News-Meinungen
Man könnte argumentieren, dass der Markt fehlerhafte und ineffiziente Software ungefähr genauso gern kauft wie ausgereifte Software – und dass eine davon die billigste Software ist, die man bauen kann.
Das ähnelt der Geschichte vom „Lemons Market“. Der Markt verkauft alle Waren so, als seien sie hochwertig, senkt aber stillschweigend die Qualität, um Grenzkosten zu reduzieren. Käufer können vor dem Kauf hohe und niedrige Qualität nicht unterscheiden, weshalb sich die Nachfrage künstlich angleicht; die Ursache ist Informationsasymmetrie.
Bei KI ist das bereits so und wird noch schlimmer werden. Nutzer können nicht unterscheiden zwischen einer ausgefeilten Machine-Learning-App und einem Schleuderprogramm einer Waschmaschine, das als KI bezeichnet wird. Das KI-Label selbst erzeugt einen Preisaufschlag, und Nutzer zahlen am Ende viel zu viel für die Waschmaschine.
Im Kern ist es dasselbe, wenn man zu viel bezahlt, weil man glaubt, miserable Software sei von Technikern und Fachleuten entworfen und geschrieben worden. 99 % der Software wird von IC1–3 geschrieben, und in den meisten Tech-Unternehmen ist eine einzelne QA-Person die einzige Instanz, die die Qualität über „Akzeptanzkriterien erfüllt“ hinaus anhebt. Gelegentlich murmelt eine Gruppe Praktikanten den „LGTM“-Zauberspruch, aber selbst das ist selten.
https://www.lg.com/uk/lg-experience/inspiration/lg-ai-wash-e...
Ich war überzeugt, dass ein besseres Produkt Menschen überzeugen und viral wachsen würde, aber so war es nicht. Es wuchs zwar, aber viel zu langsam; nach einigen Jahren war das Geld aufgebraucht, bevor wir die Gewinnschwelle erreichten.
Die Erkenntnis war: In einem umkämpften Markt sind niedrige Kosten – und damit niedrigere Qualität – ein Wettbewerbsvorteil. Je größer ein Produkt wird, desto stärker wird der Druck zur Kostensenkung, und weil Menschen das Günstige wollen, wird irgendjemand die „Kosten“, also die Qualität, kürzen und es billiger machen. Unternehmen zahlen nur das Minimum, das nötig ist, um zu überleben und profitabel zu sein.
Junge Unternehmen versuchen manchmal, hohe Qualität zu liefern, oder erhöhen kurzfristig ihre Ausgaben, aber am Ende entsteht eine Tendenz, in stabile Mittelmäßigkeit abzurutschen. Das ist etwas anderes als ein Lemons Market und scheint eher in allgegenwärtiger Mittelmäßigkeit zu enden als in einem Marktzusammenbruch.
Wenn man eine Durchschnittsperson aber zwischen Slack und dem schnellen IRC-Client Weechat wählen lässt, wird sie vermutlich die Terminal-artige UI, fehlende Videoanrufe, fehlende Webhook-Integrationen sowie fehlende Custom-Avatare oder Emojis als niedrige Qualität ansehen.
Performance ist ebenfalls ein Feature. Ein wichtiger Grund, warum Internet Explorer von Chrome verdrängt wurde, war, dass Chrome zum Start deutlich schneller war; und dass Python-Entwickler schnell zu uv/ruff wechseln, liegt ebenfalls an Performance-Verbesserungen. Wenn Slack allerdings nicht 10 ms, sondern 5 Sekunden zum Starten braucht, stören sich nur noch sehr wenige daran.
Bei fehlerhafter Software passiert das zwar manchmal, aber im Allgemeinen wollen Menschen weniger bezahlen und nehmen dafür ein paar Bugs in Kauf. Man muss nur überlegen, wie viel man verlangen müsste, wenn jede Codezeile von mehreren Engineers geprüft und viel Zeit in strenge QA-Prozesse gesteckt würde.
Als ich in Padova lebte, habe ich einmal Software für eine kleine Buchhandlung geschrieben. Weil es für einen Freund war, baute ich sie schnell und verlangte nicht viel. Sie war nicht perfekt, aber wenn Probleme auftraten, behob ich sie; es gab auch nicht viele, und mein Freund war mit dem Deal zufrieden. Weil er wusste, dass er günstig wegkam, hatte er auch Geduld.
Ich habe mehrfach gesagt: Wenn unser Team einem Kunden sagen würde: „Das Projekt ist abgeschlossen, hat aber genauso viele Bugs und UI-Albträume wie diese Backoffice-Plattform“, würden wir gerügt, zurückgestuft oder gefeuert.
Dazu gehören auch Unternehmen wie Google, denen menschlicher Support fehlt. Support zeigt sich in vielen Formen: Informationen wie Dokumentation, Videos und Blogs; Menschen, die helfen, etwa „Mama, so benutzt man Google“; Unterstützung für das, worauf etwas genutzt wird, also Betriebssysteme, Browser und Formate; und Dinge wie Excel, die die eigene Arbeitsweise selbst stützen.
Und schließlich gibt es echte Menschen. Das ist der wichtigste Grund, warum selbst das schlechteste ERP der Welt überlebt. Auch Marketing und Vertrieb signalisieren, dass es Support gibt. Wenn Unternehmenskunden nur Engineers zu Gesicht bekommen, kann das ein schlechtes Zeichen sein. Entwickler können oft viele andere Dinge nicht – und genau diese anderen Dinge sind wichtiger Support.
Selbst ein gutes Produkt stirbt ohne Support. Wenn man gegen ein schlechteres Produkt antreten will, ist es klug, den Supportbedarf durch weniger Bugs, weniger Performance-Probleme, weniger Plattformfragen usw. zu senken, um die Kosten des eigenen Teams zu reduzieren; aber Support auf anderen Ebenen muss man unbedingt ergänzen. Für ein kleines Team ist es am einfachsten, die knappste Support-Ressource bereitzustellen: Menschen. Danach braucht es Kreativität.
Außerdem muss man die eigenen Stärken gut vermitteln. Manche Menschen gewichten bestimmte Arten von Support stärker, etwa „man kann den Code besitzen vs. proprietäres Produkt“. Viele Menschen bevorzugen ein proprietäres Produkt mit Support gegenüber Code ohne Support.
Seit 1980 ist die Rechenleistung meiner Ansicht nach ungefähr um den Faktor 1000 gestiegen.
Selbst wenn Bounds Checks für dynamische Arrays 5 % kosten würden – tatsächlich ist es deutlich weniger –, wären Computer, wenn man sie überall aktiviert hätte, eben nur etwa 950-mal schneller.
Wenn man 1980 zurückginge und die Wahl hätte zwischen „einem Computer, der 950-mal schneller ist, keine große Klasse von Memory-Safety-Schwachstellen hat und das Debugging um Größenordnungen erleichtert“ und „einem Computer, der 1000-mal schneller ist, dessen Software aber weiterhin voller Bugs oder noch schlimmer ist und bei dem Debugging ein Albtraum bleibt“, dann wären die Leute schon von 950-mal beeindruckt gewesen.
Gewählt haben wir aber Letzteres, und persönlich finde ich, dass die 1000-mal-Fraktion den Rest von uns ruiniert hat.
Als sie es schließlich so optimierten, dass es auf der Sparc 20 effizient lief, entstand die Grundlage dafür, dass das Unternehmen in einem breiteren Markt Erfolg haben konnte. Optimierung sollte als Wettbewerbsvorteil behandelt werden, und in manchen Fällen kann sie sogar der wichtigste Wettbewerbsvorteil sein.
Erzwingt man also Bounds Checks, verliert diese Sprache bei bestimmten Aufgaben ihre Wettbewerbsfähigkeit.
In den meisten Fällen spielt es überhaupt keine Rolle und liegt weit unter 5 %. Ich halte eine Trennung in sichere/unsichere oder normale/Performance-Bereiche für eine gute Lösung.
Mainstream-CPUs liegen eher 1 bis 2 Millionen Mal über Maschinen aus den 80ern. Für ein paar Hundert Dollar bekommt man immer noch einen refurbished Bürorechner in der Kategorie „eine Million Mal schneller“.
Dass heutige Computer langsam sind und sich langsam anfühlen, liegt nicht einfach daran, dass Computer langsam wären – und trotzdem passiert es. Scriptsprachen, die für kleine Operationen ständig Speicher allozieren, und dynamische Typisierung, bei der man für jede Variable Zeigern folgen muss, sind ein Teil der Ursache; außerdem nutzen manche Menschen extrem ineffiziente Programme in ohnehin schlechten Umgebungen.
Die meisten heutigen Programme werden nicht so geschrieben, wie Nutzer es gern hätten, sondern so, wie die Autoren arbeiten möchten. Viele haben kein Konzept von Optimierung oder kein Gefühl dafür, was schneller läuft; sie bringen etwas zum Laufen und denken dann: „Dieses Programm hat eben diese Geschwindigkeit.“
Schon die Vorstellung, dass dieselbe Software schneller sein könnte, ist eine Nischendenkweise, und selbst auf Hacker News denkt nicht jeder so.
Sprachen mit Garbage Collection verbrauchen oft ein Mehrfaches an Speicher. Sie geben nicht mehr verwendeten Speicher nicht sofort frei und benötigen tendenziell schon von vornherein mehr Allokationen.
Durch meine Arbeit bei Google und Facebook habe ich gespürt, wie billig Hardware ist und wie wenig wert Code-Optimierung in den meisten Fällen ist.
Google begann schon vor mehr als zehn Jahren damit, die Nutzung von Data-Center-Ressourcen zu verwalten, und jedes Projekt hatte Budgets für CPU-Kerne, Festplattenspeicher, Flash-Speicher, Disk-Spindles, Arbeitsspeicher und Ähnliches. Diese Ressourcen ließen sich größtenteils ineinander umrechnen, sodass man die relativen Kosten sehen konnte.
Damals war Flash-Speicher etwa 20-mal teurer als Festplatten, war wegen Spindle-Bottlenecks aber bei den Gesamtkosten oft günstiger.
All das ließ sich in „mili-SWE“ umrechnen, also in ein Tausendstel des Aufwands, den ein SWE in einem Jahr leistet. Projekte konnten Hardware sparen und mehr Leute einstellen oder weniger Leute einstellen und innerhalb ihres aktuellen Budgets mehr Hardware bekommen.
Ich erinnere mich nicht genau, wie viele CPU-Kerne einem SWE entsprachen, aber es waren wohl Tausende. Wenn man ein SWE-Jahr in die Optimierung eines ganzen Projekts steckt und dabei nicht 5000 CPU-Kerne einspart, ist das ein Nettoverlust.
Sehr große Projekte verbrauchten weit mehr als das, sodass Optimierung dort sinnvoll war; häufig passte Optimierung aber nicht, besonders wenn der geschriebene Code wahrscheinlich irgendwann ersetzt werden würde.
Gleichzeitig gibt es im Web ein generelles Usability-Problem. Das Web sollte nicht so viele Ressourcen verbrauchen, wie es das heute tut. Wer jemanden kennt, der Dateneingabearbeit gemacht hat, weiß, dass die Maus ziemlich ineffizient ist. Textbasierte Terminals vor 30 bis 40 Jahren boten sehr effiziente Interfaces bei sehr geringem Ressourcenverbrauch.
Ich dachte einmal, das Web würde irgendwann „gelöst“, indem sich ein allgemein erwarteter Tech-Stack etabliert und man zu anderen Problemen übergeht, aber so kam es nicht. Es gibt immer noch das „Framework der Woche“, und man macht dumme Dinge wie Scrollbars in Nutzer-Code neu zu implementieren, die nicht richtig mit dem Mausrad zusammenspielen. Ich weiß nicht, wie man dieses Problem lösen könnte, oder ob es überhaupt „lösbar“ ist.
Google investierte enorme Anstrengungen in zwei andere Performance-Aspekte: Latenz und die Gesamtauslastung der Maschinen. Beides waren Vorgaben von oben, zog die Zeit und Aufmerksamkeit Tausender Engineers auf sich und verursachte hohe Personalkosten.
Wenn Maschinen aber der Engpass sind, will man einzelne Kerne nicht grundlos ungenutzt lassen, selbst wenn sie billig sind. Denn die Opportunitätskosten, auf den Bau eines neuen Data Centers zu warten, sind hoch. Wenn die Nutzung sehr latenzsensitiv ist, ergibt es Sinn, Millisekunden nicht wegen eingesparter Hardwarekosten zu reduzieren, sondern wegen Geschäftskennzahlen.
Die Bewertung sollte anhand der Grenzkosten erfolgen. Selbst wenn man pro Dollar nur ein paar Cent pro Jahr spart, ist es besser, diese Arbeit zu tun, als Engineers untätig herumstehen zu lassen.
Das Problem ist, dass das fast niemand so macht. Die Entscheidungsfindung hat nichts mit ökonomischer Kalkulation zu tun; die meisten folgen einfach dem, „was Google macht“. Das erklärt viele Funktionsstörungen.
Für normale Unternehmen, selbst große, gilt das aber nicht in diesem Maß. Es wirkt wie ein typisches Beispiel für: „Facebook/Google/Netflix usw. sind eine eigene Klasse, und die meisten ihrer Praktiken funktionieren bei euch nicht.“
Man kann sich ein Paralleluniversum vorstellen, in dem Human Resources in Optimierung gesteckt werden, aber dieses Universum wäre völlig anders als unseres. Wenn man einen zusätzlichen Engineer für Optimierung einsetzt, hat man einen Feature-Engineer weniger. Wofür? Um ein paar CPU-Zyklen zu sparen? Das wirkt einfach lächerlich.
Allein vom Titel her dachte ich, Carmack würde schlecht optimierte Software kritisieren und dafür plädieren, die Performance auf älterer Hardware zu verbessern.
Der eigentliche Tweet ist aber keines von beidem, sondern behandelt ein Gedankenexperiment, in dem die Hardware-Entwicklung zum Stillstand kommt, und kommt zu dem Schluss: „Ohne extrem günstige, skalierbare Rechenleistung wären innovative neue Produkte natürlich deutlich seltener.“
https://news.ycombinator.com/item?id=43967208
https://threadreaderapp.com/thread/1922015999118680495.html
Ich sehe eher, dass wir in den 18 Jahren seit dem Smartphone kaum große Innovationen gesehen haben, weil Kapital auf Hardware-Fortschritt setzt, um Verbrauchern Produkte zu verkaufen, die im Kern dem entsprechen, was sie bereits haben.
Allerdings konnte ich nach dem ersten Tweet nicht weiterlesen.
Es wird eine Stagnation geben, aber keine anhaltende.
Wenn man Leute mit weniger komplexen Sprachen einstellen und produktiv machen kann, wird der Arbeitsmarkt größer und die Kosten sinken.
Im Original behauptet Carmack im Grunde: „Gute, kluge Entwickler sind teuer, und weil es Wichtigeres gibt, gibt man kein Geld dafür aus, Code und Systeme bis zum Ende zu optimieren; deshalb ist Software langsam.“
Daraus folgt: Wenn gute Entwickler plötzlich sehr billig würden, könnten alle sie einkaufen und für Optimierung einsetzen, wodurch viele Software plötzlich schneller werden könnte. Warum also könnten gute Entwickler plötzlich billig verfügbar werden?
Es wäre gut, wenn man die Lebensdauer von Hardware nach der „geplanten Obsoleszenz“ um 5 oder 10 Jahre verlängern könnte.
Damit ließe sich viel Elektroschrott vermeiden, seltene Erden blieben im Boden, und auch die Treibhausgasemissionen könnten deutlich sinken.
Aber die Marktkräfte in der Softwareproduktion bezahlen nicht für solche externen Effekte. Schnell veröffentlichen, testen und iterieren ist viel billiger, als für Performance zu planen und zu entwerfen. Einige Organisationen in der Spielebranche haben eine Formel gefunden, mit der sie gute Performance und hohe Verkaufszahlen zugleich erreichen, aber sie hat sich nicht gleichmäßig verbreitet.
Bei Unternehmens- und Verbrauchersoftware gibt es wenig Anreiz, Performance-Kriterien in die Anforderungen aufzunehmen. Man entwirft auf ein Niveau, das Nutzer noch tolerieren, und lässt möglichst viel Spielraum, weil ständig Änderungen und Funktionen ausgeliefert werden müssen. Jede Änderung ist eine Schuld, die Performance und Nutzerzufriedenheit beeinflussen kann, also schafft man Budgetpuffer, um Fehlerraten abzufedern.
Das unterscheidet sich stark von der früheren Art, hinter verschlossenen Türen zu entwerfen und zu entwickeln, „bis es fertig ist“.
Wir sollten eine Wirtschaft haben, die auf Pflege und Wartung ausgerichtet ist, und makroskopische Anstrengungen am Wohl der gesamten Menschheit ausrichten statt am wahrgenommenen Reichtum einiger weniger.
Hätten wir uns auf die Wartung alter Fahrzeuge, die Wiederverwendung alter Computer usw. konzentriert, wären Deponien im Verhältnis zum Wachstum kleiner gewesen.
Natürlich gibt es vermutlich auch eine spieltheoretische Konstruktion, die zeigt, dass Konservatismus objektiv die unterlegene Strategie ist.
Seit über 10 Jahren ist es bereits möglich, die Order-Matching-Engine einer ganzen Börse in einem einzigen Thread laufen zu lassen.
Ich denke, eine bestimmte Klasse von Rechenleistung, nämlich streng serialisierte Transaktionsverarbeitung, ist nicht so schnell gewachsen, wie andere Kennzahlen vermuten lassen. 31 zusätzliche Kerne machen eine Order-Matching-Engine nicht schneller; sie können sie sogar langsamer machen.
Wenn ein Produkt weniger als ein paar Millionen Transaktionen pro Sekunde verarbeitet und trotzdem nach einem Maschinencluster sucht, sollte man etwa 15 Schritte zurückgehen und von vorne anfangen.
Das ursprüngliche Design hätte immer noch 99 % der Anwendungsfälle erfüllt, und angesichts der heutigen lokalen Rechenleistung könnte man sogar den gesamten Markt auf einer einzigen Maschine betreiben.
Liegt es daran, dass außer dem Sortieren nach Zeit und Preis nicht genug weitere Berechnung anfällt?
Wenn pro Transaktion komplexere Verarbeitung nötig wäre, könnte man nicht so viele davon verarbeiten. Welche komplexere Verarbeitung nötig sein könnte, ist allerdings schwer vorstellbar, wenn man nicht aus dieser Domäne kommt.
Stimmt. Das ist ein ökonomisches Problem, also ein Problem der Ressourcenallokation
Es ist die Entscheidung, ob man jemanden mehr Zeit in Software-Optimierung stecken lässt oder ihn mehr Funktionen bauen lässt. Wenn Letzteres mehr Cash erzeugt, wird man ihn das tun lassen; wenn Ersteres für den Cashflow wichtig wird, wird man ihn das tun lassen
Das ist ein klares Beispiel für negative externe Effekte, die Softwareunternehmen der Allgemeinheit auferlegen. Die meisten Softwareunternehmen kümmern sich nicht um Optimierung, weil sie nicht die tatsächlichen Kosten für Energie, verlorene Zeit und zusätzlichen Elektroschrott tragen
Gründliche Optimierung ist in vielen Fällen nicht besonders relevant, aber die Vorstellung, einfach mehr Server hinzustellen, statt neu zu schreiben, ist ein trauriger Zustand
Die meisten neuen Funktionen von macOS, Windows und Android nutze ich nicht. Was ich will, ist eine effiziente Umgebung zum Ausführen von Apps und Sicherheitsverbesserungen. Auch viele Verbesserungen wie die Einstellungen-App von macOS sind nicht besonders zufriedenstellend
Bei Designsoftware ist es genauso. Die meisten neuen Funktionen, die Adobe eingebaut hat, nutze ich nicht, und ich könnte mit Illustrator oder Photoshop von vor 10 Jahren völlig zufrieden sein. Was ich will, ist weniger aufgeblähte Software
Bei Audio- und Musikproduktion will ich neue Funktionen, weil sich die Workflows noch verbessern, aber nicht auf Kosten der Effizienz
Bei Code-Editoren reichen mir die Funktionen von VSCode. Mehr brauche ich nicht; ich möchte zwar bessere LSPs, aber das gehört nicht zum Kern des Editors. Allerdings wünschte ich, VSCode wäre schneller und würde weniger Speicher verbrauchen
Software-Optimierung ist auf ähnliche Weise attraktiv. Aber wenn das Problem lautet: „ein paar Stunden teure Engineering-Zeit für Optimierung“ oder „billigen RAM dazustecken“, gewinnt die günstigere Wahl. Manchmal ist das Problem groß genug, dass sich Optimierung lohnt
Der Markt wird entscheiden, welche Option es wert ist, verfolgt zu werden. Wenn bei der Methode, einfach mehr Hardware draufzuwerfen, abnehmende Grenzerträge erreicht sind, wird man Software optimieren. Mooresches Gesetz verlangsamt sich, aber diesen Punkt scheinen wir noch nicht erreicht zu haben
In der Realität ist es aber eher umgekehrt. Wenn ein niedrigerer Preis daransteht, werden sie auch eine Version mit geringerer Leistung bevorzugen
Es ist weniger ein Gegenargument zu Carmack als ein konkretes Beispiel, an das ich manchmal denke
Electron-Apps liegen bei Verbrauchern irgendwo zwischen „wegen Performance-Problemen ertragen“ und „verhasst“, aber sie sind möglicherweise die einzelne Innovation, die Linux-Laptops am Arbeitsplatz praktisch nutzbar gemacht hat. Zum Beispiel ist es wirklich nützlich, ohne Installation an einem MS-Teams-Meeting teilnehmen zu können
Deshalb klagen alle, dass heute nichts mehr so dicht programmiert ist wie Winamp, vergessen dabei aber die ersten drei Buchstaben
Die Chancen stehen recht gut, dass sie auch unter Linux läuft, aber Electron-Software ist auf jeder Plattform miserabel
2010 habe ich als Reinigungskraft gearbeitet und nebenbei quasi den IT-Verantwortlichen gegeben
Ich sagte der Firma damals, dass Laptops aus den letzten fünf Jahren, grob alles ab Nehalem, für Tabellenkalkulationen ausreichend leistungsfähig seien. Das war im Grunde alles, was sie machten, und zwei Kerne, 16 GB RAM und eine 500-GB-SATA-SSD reichten. Nur ein paar Leute im Marketing brauchten etwas stärkere Geräte, aber der Unterschied war nicht groß, und wir sparten viel Geld, weil wir nicht die neuesten High-End-Laptops kauften
Ich arbeite heute nicht mehr dort, bin aber überzeugt, dass diese Computer auch heute noch für Tabellenkalkulationen völlig ausreichen müssten. Die Arbeitsabläufe haben sich kaum verändert; verändert hat sich die Software. Wenn sie ständig aktualisiert wurden, weiß ich nicht einmal, ob sie heute MS Windows 10 oder 11 „ausführen“ können, aber durch Aufblähung und besonders durch reine Online-Tabellenkalkulationen ist die Produktivität vermutlich stark gesunken
Das Internet dort war ebenfalls miserabel. Die Optionen waren entweder etwa 16 Mbit asymmetrisches DSL für 300 Dollar im Monat, weil es „Business“ war, oder Comcast-Kabel mit 120 Mbit für 500 Dollar im Monat. Selbst 120 Mbit reichen für reine Online-Tabellenkalkulationen gerade so, und 16 Mbit sind definitiv zu wenig. Noch schlimmer ist, dass das Geschäft stillsteht, wenn das Internet ausfällt
Genau das ist der Diebstahl, von dem ein anderer Kommentar sprach, und ich stimme dem vollkommen zu. Es gibt überhaupt keinen Grund, warum ein Laptop, der im Büro Tabellen bearbeitet und aktualisiert, Internet oder absurde Rechen- und Speicherressourcen oder große Bandbreite benötigen sollte
Für die schreckliche Performance heutiger Computer gibt es keine Entschuldigung, außer dass die Kosten auf Kunden abgewälzt werden, also sowohl auf Privatpersonen als auch auf Unternehmen
https://news.ycombinator.com/item?id=43971960
Die Welt läuft nicht auf eleganter, schneller und fehlerfreier Software, sondern auf Funktionen
Für Endnutzer gibt es keinen Unterschied zwischen einer fehlenden Funktion und einem Bug. Es gibt auch keinen nennenswerten Unterschied zwischen schlechter Performance, durch die eine Aufgabe 5 Minuten dauert, und einer fehlenden Funktion, wegen der Nutzer dieselbe Sache 5 Minuten lang manuell erledigen müssen. Beides ist „langsam“
Wenn man den Wert für Endnutzer immer weiter maximiert, baut man zwangsläufig langsame, fehlerreiche Software. Außerdem sagen Nutzer überraschenderweise nein, wenn man sie fragt, ob sie schnellere, weniger fehlerhafte Software wollen, wenn dafür Funktionen wegfallen. Noch wichtiger ist: In der Unternehmenswelt sind die Käufer von Software oft nicht die Endnutzer, und sie wollen mehr Funktionen und weniger Performance und Eleganz
Bei gleichem Funktionsumfang würden Nutzer und Käufer die schnellste, fehlerärmste und eleganteste Software wählen. Fehlt aber auch nur eine Funktion, verliert man. Der Grund, Software schnell und elegant zu halten, ist, dass man so mit der größten Wahrscheinlichkeit weiter Funktionen hinzufügen kann, ohne zu einem Produkt mit weniger Funktionen zu werden
Schnelle und elegante Lösungen können gute Reviews bekommen und Lob dafür, dass sie sich gut anfühlen. Deshalb kann das wie ein wichtiger Faktor wirken. Aber wenn sie am Ende nicht das tun, was man will, kauft man sie gar nicht. Wenn eine zentrale Funktion benötigt wird, entscheidet man sich für das langsame, nervige, fehlerhafte Chaos
Man sollte auch nicht vergessen, dass Microsoft Nutzer inzwischen tretend und schreiend zur nächsten Windows-Version zerren muss. Hätte man die Nutzer selbst entscheiden lassen, hätten viele seit Windows XP nicht mehr upgegradet. Und das, obwohl spätere Versionen viele hübsche neue Funktionen hatten
Ich stimme zu, dass Unternehmen und Investoren Funktionen an sich wollen, aber Nutzer ganz sicher nicht
Wenn es möglich wäre, würde niemand mehr irgendetwas upgraden. Man muss sich nur ansehen, wie sehr Microsoft sich abmüht, Leute zum Upgrade zu bewegen. Ich habe noch nie jemanden gehört, der gesagt hätte, er habe sich eine neue Version von Windows, Office, Slack, Zoom usw. gewünscht
Das ist auch der Grund, warum alles wie Photoshop in die Cloud gezwungen wird. Die Mehrheit der Leute will die angebotenen neuen Funktionen nicht, Unternehmenskäufer eingeschlossen. Die Antwort zur Aufrechterhaltung des Umsatzes ist, Leute zum Kaufen zu bringen, unabhängig davon, ob Funktionen geliefert werden oder nicht
Allerdings erledigen bestehende Nutzer mit der Software bereits das, was sie brauchen; neue Funktionen können ihnen also ermöglichen, andere Software abzuschaffen oder neue Dinge zu tun. Wenn diese neue Sache aber wirklich unglaublich wichtig wäre, hätten sie bereits andere Software dafür gesucht und genutzt, was bedeutet, dass sie bisher auch ohne ausgekommen sind. Deshalb denke ich, dass bestehende Nutzer, wenn sie wirklich reflektiert wären, zuerst Performance-Verbesserungen verlangen würden und vielleicht ein paar kleinere Verbesserungen
Potenzielle Nutzer hingegen kennen die Software noch nicht oder brauchen noch irgendeine andere Funktion, bevor sie sie nützlich finden. Sie sind diejenigen, die vernünftigerweise nach neuen Funktionen suchen
Daher ist die Entscheidung „Funktionen vs. Performance“ auch ein Signal dafür, ob Entwickler die Gewinnung neuer Nutzer oder die Zufriedenheit bestehender Nutzer priorisieren. Dass Techniker Letzteres bevorzugen, ist selbstverständlich. Sie haben dieses Spiel schon gespielt und wissen, dass sie in der langen tatsächlichen Nutzungszeit priorisiert werden wollen, nicht während der Akquise
Dass fehlerreiche und langsame, aber funktionsreiche Software den Markt dominiert, liegt auch daran, dass Unternehmen Wachstum zuerst priorisieren. Die Geschichte ist voll von schöner, eleganter Software, nach der sich Nutzer sehnen, die sich aber nicht weit genug verbreitet hat, damit das Unternehmen bestehen konnte
Der Trade-off ist in beide Richtungen real. Die meisten Menschen verbringen mehr Zeit als Nutzer denn als potenzielle Nutzer. Das ist wahrscheinlich ein wichtiger Grund für die verbreitete Wahrnehmung, dass heutige Software und Computer unglaublich schlecht sind
Das Geld, das bei Heim- und Bürocomputern für RAM und bessere CPUs ausgegeben wird, ermöglicht es, die gesamte darauf laufende Software günstiger und mit mehr Funktionen auf den Markt zu bringen