Fast – die Kraft schneller Software

• In der Softwareentwicklung wird selten explizit Schnelligkeit (fast) eingefordert, aber schnelle Software verändert das Verhalten der Nutzer
• Technologien wie schnelle Deployments und Echtzeit-Streaming verbessern Arbeitseffizienz und Remote-Arbeit grundlegend
• Langsame Software erzeugt kognitive Reibung und ist tatsächlich ein wesentlicher Faktor, der die Produktivität der Nutzer deutlich senkt
• Schnelle Software verbirgt Komplexität nicht, sondern zeigt Einfachheit und Fokus
• In der Entwicklungsbranche dürfte sich künftig der Trend verstärken, Performance und Experience-Optimierung in den Mittelpunkt zu stellen

---

Eine Softwarebranche, die selten Schnelligkeit verlangt

• In der Softwarebranche werden meist Funktionen, Preis, Datenintegration usw. gefordert, aber nur selten direkt „Schnelligkeit“
• Doch schnelle Software hat die Kraft, das Nutzerverhalten selbst zu verändern
• Wenn sich das Deployen von Code auf Sekunden verkürzt, steigt auch die Deployment-Frequenz der Entwickler
• KI-basierte Code-Autovervollständigung erleichtert das Prototyping in unvertrauten Sprachen
• Echtzeit-Streaming eröffnet neue Möglichkeiten für Remote-Arbeit

Die Grenzen langsamer Software

• Langsame Software schränkt uns mehr ein, als wir denken
• Ein Beispiel ist die Erfahrung, mit Flugzeug-WiFi arbeiten zu wollen und dabei kaum produktiv sein zu können
  • Man schafft vielleicht noch das Senden von Slack-Nachrichten oder das Beantworten von E-Mails,
  • Google Docs funktioniert jedoch oft nicht richtig
  • Am Ende ist es eine Nutzererfahrung, bei der man schließlich aufgibt
• Dienste wie Instagram bieten dagegen durchgängig eine schnelle Experience

Die Wirkung schneller Software

• Schnelligkeit wirkt magisch
• Schnelle Software beseitigt kognitive Reibung und reagiert wie bei Raycast oder Superhuman einen Schritt schneller als erwartet
• Die Reaktionszeit von unter 100 ms bei Superhuman und die hervorragende Unterstützung von Shortcuts revolutionieren das E-Mail-Erlebnis
• Auch die Sofortüberweisung von Mercury überrascht Nutzer, die an langsame Banktransaktionen gewöhnt sind
• Die Geschwindigkeit dieser Tools wird selten ausdrücklich gelobt, ist aber der Grund, warum sie sich für Nutzer fast magisch anfühlen

Schnelligkeit, Einfachheit und Fokus

• Schnelligkeit bedeutet zugleich Einfachheit und ist in modernen Softwareumgebungen ein immer seltenerer Wert
• Damit Software schnell wird, ist die bewusste Entfernung unnötiger Funktionen nötig
• Schlanke Projektmanagement-Tools wie Linear bieten im Vergleich zu Enterprise-Apps wie Workday oder Oracle eine deutlich schnellere Nutzungserfahrung
• Schnelligkeit ist ein Zeichen von Respekt gegenüber dem Nutzer und zeigt, dass Unnötiges konsequent herausgefiltert wurde

Der verborgene Aufwand hinter schneller Software

• Um schnelle Software zu bauen, sind komplexe Backend-Optimierungen erforderlich
• Bei Cash App bemühte man sich, nur die wirklich notwendigen Schritte in der User Journey hinzuzufügen, während die Komplexität intern verarbeitet wird
• Instagram begann beim Hochladen eines Fotos bereits während der Eingabe der Bildunterschrift mit dem Upload, sodass Nutzer das Gefühl hatten, der Upload sei sofort erfolgt
• Schnelligkeit ist nicht nur eine technische Leistung, sondern das Ergebnis von Priorisierung und Fokus

Schnelligkeit als Spaß und Motivation

• Schnelle Software vermittelt an sich schon Spaß und Zufriedenheit
• Selbst bei kleinen Dingen wie der Messung der Tippgeschwindigkeit (WPM) oder dem Einrichten von Shortcuts genießen Nutzer die Erfahrung, schneller zu werden

Die Relativität von Schnelligkeit

• AI- und LLM-basierte Workflows bieten im Vergleich zu traditionellen Vorgehensweisen eine deutlich schnellere Experience
• Zum Beispiel erzeugt es im Vergleich zu früher eine mehr als 10.000-fach höhere Produktivität, wenn man in 6 Minuten ein LLM mit Recherche beauftragt
• Dennoch gibt es bei der Entwicklung, dem Build und dem Deployment von AI-Apps noch viele Defizite gegenüber früheren Software-Generationen
• Aktuell liegt der Fokus noch stärker auf neuen Funktionen als auf Performance und Experience
• In Zukunft wird ein Trend kommen, der Optimierungen bei niedriger Latenz, Interface-Design, Konnektivität und Zuverlässigkeit priorisiert
• Dadurch werden sich mehr neue Möglichkeiten und eine Weiterentwicklung der Nutzererfahrung eröffnen

Referenzmaterial

• Nützliche zusätzliche Materialien zum Thema Schnelligkeit sind die folgenden Texte
  • Patrick Collison: https://patrickcollison.com/fast
  • Charlie Marsh: https://notes.crmarsh.com/python-tooling-could-be-much-much-faster
  • Paul Graham: https://www.paulgraham.com/growth.html

[GN⁺]

Hacker-News-Kommentare

• Ich bin YCom wirklich dankbar dafür, dass sie die HN-Oberfläche schnell und gut erhalten. Ich erinnere mich noch daran, wie Slashdot wegen einer „modernen UI“ die Oberfläche komplett umgebaut hat und sie danach voller riesiger Leerflächen und schwer scanbarer Strukturen war, sodass ich sofort abgesprungen bin. Früher habe ich die Seite täglich gelesen.
  • Informationsdichte und das schnelle Finden der gewünschten Informationen sind praktisch das genaue Gegenteil von „Engagement“. Oft werden Seiten absichtlich kompliziert gemacht, um die Verweildauer zu erhöhen und damit bei Werbekunden besser dazustehen. Seiten werden absichtlich langsam geladen, damit man falsch klickt und zu „Conversions“ gedrängt wird. In der Realität lohnt es sich finanziell oft eher, Leute auszutricksen, als sich wirklich am Nutzer zu orientieren.
  • HN ist die Seite, die ich öffne, um zu prüfen, ob meine Internetverbindung funktioniert. Inmitten all des Web-Bloats ist sie wirklich ein leuchtendes Beispiel.
  • Auch die HN-UI braucht Verbesserungen, besonders auf Mobilgeräten. Der Kontrast ist zu niedrig, die Buttons sind zu klein und schwer zu bedienen, es gibt keinen Dark Mode und so weiter. Ich habe eine Version meiner idealen UI in Elm gebaut, komplett clientseitig, mit der HN Firebase API: https://seville.protostome.com/
  • Ich glaube nicht, dass Slashdot wegen der UI untergegangen ist. Der eigentliche Wert lag in den hochwertigen Kommentaren der SMEs ganz am Anfang. Nach dem Verkauf der Seite ging es wohl bergab: schwächere Nutzer, schlechtes Management, Abwanderung. Es ist erstaunlich, dass die Seite überhaupt noch lebt.
  • Die orangefarbene Seite (HN) unterstützt immer noch keine Markdown-Link-Tags.
• Ich habe oft das Gefühl, dass Workflows mit LLMs in der Praxis langsamer sind. Die „Refactor“-Funktion einer IDE ist in 1 Sekunde fertig, ein AI-Assistent braucht 30 Sekunden, ein „Agent“-Ansatz 15 Minuten. Ich hatte zum Beispiel einem Agenten Code für einen HTTP-Endpunkt überlassen und zuerst gedacht: „Einen ganzen Tag Arbeit in 10 Minuten erledigt.“ Beim erneuten Ansehen war die Logik aber verworren und das Error-Handling schwach. Am Ende habe ich selbst noch etwa 5 Stunden neu implementiert, Tests geschrieben und es auf ein Niveau gebracht, das meine Anforderungen sogar besser erfüllte als der Agent. Es gibt dazu auch Forschung: https://www.reddit.com/r/programming/comments/1lxh8ip/study_finds_that_ai_tools_make_experienced/
  • Ich habe über dieses Thema schon mehrfach geschrieben. Dass LLMs Benchmark-Scores hinterherlaufen, halte ich aus Sicht von Programmier-Tools für die falsche Richtung. Meiner Erfahrung nach liegen sie mit recht hoher Wahrscheinlichkeit falsch, also muss man die Ergebnisse immer prüfen. Dadurch verlängert sich das Hin und Her mit dem LLM, und weil die Antworten langsam kommen, habe ich oft das Gefühl, dass ich es von Hand schneller selbst bauen könnte. Was ich mir wünsche, ist ein Agent, der vielleicht nur auf 60-%-Benchmark-Niveau liegt, aber in unter 1 Sekunde antwortet.
  • Wirklich schneller gemacht haben mich LLMs bisher nur bei einer Art fortgeschrittenem Find/Replace für Code. Zum Beispiel bei Prompts wie: Ersetze an mehreren Stellen im Code die „XXX-bezogene Logik“ durch etwas anderes. Darauf antworten sie oft ziemlich gut. Das erspart viel mühsames manuelles Suchen und Anpassen. Mit extrem großen Codebasen habe ich das allerdings noch nicht ausprobiert.
  • Es hängt wohl von der Situation ab. Refactorings gehen viel schneller, wenn IDE oder Language Server sie direkt unterstützen, aber sonst können LLMs helfen. Ich habe zum Beispiel gestern eine MVP-Logik zur URL-Normalisierung gebaut, bei der es wegen sehr unterschiedlicher URLs in Kundendaten viele Prüf-Fälle gab. Ich habe Claude die häufigsten Kundenbeispiele gegeben und um „minimale Spannbaum-Testfälle“ gebeten; nach 5 bis 10 Sekunden kam ein Ergebnis zurück. Darauf aufbauend habe ich mit der Opus-Agent-Funktion in Zed die Testdatei erzeugt, die Fälle überprüft, Unnötiges bereinigt und die Logik weiter verbessert. Das war deutlich schneller, als alles allein zu bauen.
  • Ich höre online wie offline oft, dass Senior-Arbeit damit 40 bis 60 % schneller wird. Trotzdem wirkt es noch nicht so, als könnte man AI-Agenten schon blind vertrauen und den Rest einfach schleifen lassen.
• Das ist eine Episode aus meiner Anfangszeit, in der ich mir als Software Engineer einen Ruf damit erarbeitet habe, Dinge schneller zu machen. Damals waren sowohl Algorithmuswissen als auch die Fähigkeit, Compiler-Ausgaben zu lesen, wichtig, und es war die Zeit, in der Carmak und Abrash zu Stars wurden. Mit 22 nahm ich zum ersten Mal an einem Meeting mit einem großen multinationalen Kunden teil, und dort wurde angesprochen, dass unser Produkt zu langsam sei. Ich war vollkommen schockiert, als ich den VP der Firma sagen hörte: „Eine Sekunde schneller bedeutet für uns 1 Million Dollar mehr Jahresgewinn.“ Das war der prägende Moment, in dem ich zum ersten Mal erlebt habe, wie direkt Geschwindigkeit in Geld übersetzt wird. Selbst 20 Jahre später ist das einer der Höhepunkte meiner Laufbahn. Und ein anderer Engineer fragte den VP scherzhaft: „Wenn wir es auf 0 Sekunden bringen, verdienen Sie dann unendlich viel Geld?“ Im Raum hat niemand gelacht, aber ich fand es ziemlich witzig.
  • Würde das dann nicht heißen, dass sowohl von 1 auf 0 Sekunden als auch von 2 auf 1 Sekunden jedes Mal 1 Million Dollar dazukommen? Warum daraus plötzlich unendliches Geld folgen soll, ist schon eine seltsame Logik.
  • Mich würde am Ende interessieren, ob es tatsächlich schneller geworden ist.
• Ich stimme dem ersten Satz des Blogposts zu und wollte darauf reagieren. Nutzer sagen Entwicklern nicht direkt „Bitte macht es schnell“, aber wenn es nicht schnell ist, vertrauen sie einem auch nicht. Wenn Rust langsamer als Ruby wäre, würde sich niemand dafür interessieren. Aufmerksamkeit bekommt Rust, weil es heißt: „schneller als C++“. Auch auf HN reicht das Attribut „schnell“, damit alle wie verzaubert begeistert sind. Schon ein kleines bisschen schneller, und sofort ist die Aufmerksamkeit da.
  • Das gilt nur für die kleine Schicht von Programmierern, die auf HN schreibt. Die meisten Entwickler oder normalen Nutzer kümmern sich kaum darum, ob etwas langsam ist; Hauptsache, die UI ist bequem. Selbst professionelle Data Scientists nutzen oft lieber ein ordentliches Github Desktop als superschnelle Kommandozeilen-Tools.
  • Die Schlussfolgerung scheint falsch zu sein. „Schnell“ ist ein starkes Unterscheidungsmerkmal, wenn dieselbe Funktionsmenge schneller geliefert wird. Menschen strömen zu „X, aber schneller als X“, aber sie wechseln auch wegen mehr Funktionen, besserer UX, niedrigeren Preisen oder einfach einer insgesamt besseren Lösung. Man kann sich also auch für etwas Langsameres entscheiden.
  • Bei Sprachen und Runtimes ist Geschwindigkeit wichtig, aber bei Frameworks zählen oft andere Faktoren wie Features oder Kompatibilität mehr. Selbst etwas Langsames wie Electron wird von vielen genutzt.
  • Wir leben tatsächlich in einer Welt, in der viele Apps, besonders Web-Apps, extrem langsam sind. Es ist völlig normal, dass nach einer Nutzeraktion erst nach mehreren Sekunden eine Reaktion kommt. Selbst wenn „schnell ist das Beste“ behauptet wird, sieht die Realität oft anders aus.
  • HN-Nutzer mögen „schnell“, weil wir wissen, dass ein Großteil der Technologie, die wir heute nutzen, viel zu langsam ist — und dass sie im Kern deutlich schneller gebaut werden könnte.
• Umgekehrt gibt es auch das Phänomen, dass etwas „zu“ schnell ist und man sich fragt, ob es wirklich korrekt gearbeitet hat. Beim Beispiel TurboTax dauerte die eigentliche Analyse nicht einmal 1 Sekunde, aber nachdem absichtlich ein künstlicher Ladebildschirm eingebaut wurde, vertrauten die Leute dem Ergebnis mehr und mochten es lieber. Obwohl die Verarbeitung in Wirklichkeit viel kürzer dauerte, ließ man sie absichtlich langsamer wirken, damit die Nutzer glaubten, es sei wirklich geprüft worden.
• Geschwindigkeit ist auch auf der Kostenseite wichtig. In der Cloud, wo pro Sekunde abgerechnet wird, kann man keinen günstigen Transkriptionsservice für die ganze Firma anbieten, wenn man nicht jeden Schritt optimiert. Zum Beispiel habe ich mein Image auf ein 2,5-mal kleineres Format als das der Open-Source-Alternative gebracht, was zu schnellerem Cold Boot, geringeren Kosten und besserem Service geführt hat: https://speechischeap.com
  • Ist S3 langsam oder schnell? In Wirklichkeit beides. Ein einzelner Request ist langsam, aber wenn man viele Requests parallel abschickt, fühlt es sich schnell an. Am Ende ist „schnell“ manchmal überlebenswichtig und manchmal eine ästhetische Eigenschaft.
  • Ich gehe den umgekehrten Weg und betreibe Services auf Consumer-Hardware, viel günstiger als in der Cloud. Um Image-Größen muss ich mich nicht kümmern (Bare Metal ist schneller). Ich biete bereits gratis Transkription von 20.000 Minuten pro Minute an (bei einem Request-Limit von 5 Sekunden). Ich arbeite auch an Open-Source- und plattformübergreifenden Alternativen: https://geppetto.app https://github.com/Mozilla-Ocho/llamafile/tree/main/whisper.cpp https://github.com/cjpais/whisperfile https://handy.computer Wer Interesse an Innovationen bei Transkriptionsdiensten hat, kann sich gern melden.
  • Ich würde erwarten, dass ein Tool wie PAPER zumindest unter Linux bei einer gesamten Installationsgröße von unter 2 MB bleibt, selbst inklusive Cache. pip braucht 10 bis 15 MB, pipx noch mehr, uv 35 MB. Ich versuche, unter diese Größen zu kommen.
  • Schnell heißt nicht automatisch leichtgewichtig und effizient. Oft wird etwas schnell gemacht, indem man einfach sehr viel teure Hardware darauf wirft.
• Wenn ich Beschwerden über amerikanische Banküberweisungen sehe, muss ich mich immer daran erinnern: In Großbritannien oder der Schweiz sind Banküberweisungen fast sofort erledigt. Ich frage mich, warum das in den USA so langsam ist.
  • US-Regionalbanken haben fast nie eigene Programmierer und sind von „Core Processors“ abhängig. Deshalb verlaufen System-Upgrades sehr langsam. Die Einführung von Faster ACH hat Jahre gedauert, und Lobbygruppen regionaler Banken haben eine Verschiebung gefordert, weil sie ihnen schade. Dazu gibt es einen sehr guten Blogpost: https://www.bitsaboutmoney.com/archive/community-banking-and-fintech/
  • ACH ist wegen Taktung und Batch-Verarbeitung langsam. Die Überweisung selbst könnte sofort passieren, wird aber meist erst um Mitternacht gesammelt verarbeitet. Deshalb sind in den USA Venmo und Zelle so beliebt. Auch in der Schweiz sind IBAN-Überweisungen langsam, und bei Echtzeitzahlungen ist TWINT führend (per QR-Code). Auch das britische BACS ist aus demselben Grund eher langsam.
  • In den USA gibt es tatsächlich zwei Echtzeit-Überweisungssysteme: RTP und FedNow. Immer mehr Banken nehmen daran teil: https://real-timepayments.com/Banks-Real-Time-Payments.html Früher konnte man gegen eine kleine Gebühr auch über Kreditkartennetze sofort Geld senden. Kreditkarten haben allerdings andere Garantien und Rückerstattungsregeln, und bei Betrug ist der Schaden für Banken größer.
  • Das hat für Verbraucher zum Teil sogar Vorteile. Wenn zum Beispiel per Lastschrift Geld von einem Konto ohne Guthaben eingezogen wird, verschickt die Bank oft mehrere Warn-E-Mails. Wäre das in Echtzeit, wäre das Problem sofort da; so bekommt man aber erst eine Benachrichtigung und hat noch Zeit, selbst etwas zu unternehmen, um Mahn- oder Strafgebühren zu vermeiden. Gerade weil es keine Sofortüberweisung ist, informiert die Bank einen rechtzeitig und man kann noch reagieren.
  • patio11 hat dazu einen ausführlichen Artikel geschrieben: https://www.bitsaboutmoney.com/archive/the-long-shadow-of-checks/
• Der Artikel war interessant und hat viel Stoff zum Nachdenken geliefert. Wenn Geschwindigkeit wirklich spürbar wird, ist nicht der tatsächliche Durchsatz entscheidend, sondern die „gefühlte Schnelligkeit“ — also Dinge wie UI-Reaktionsfähigkeit oder Input-Latenz. Deshalb mag ich Go inzwischen lieber als Rust. Go kompiliert schnell genug, dass es sich fast anfühlt, als müsse man die Zeit gar nicht messen. Umgekehrt mag ich Langsamkeit einfach nicht, selbst wenn der echte Durchsatz gut ist (wie bei Java-Startups).
  • Selbst im Vergleich zwischen Go und Rust fühlt sich die Kompiliergeschwindigkeit wirklich wichtig an. Bei Rust enthalten Builds oft viele zusätzliche Dependencies, sodass die Projektstruktur ein bisschen an JavaScript erinnert. Go hat im Vergleich deutlich weniger Dependencies, und das gefällt mir.
  • Es ist schön, dass Entwickler darüber diskutieren, aber in der Praxis ist entscheidend, welche Sprache für den Nutzer schneller ist.
• Anders als die Aussage „In Software hört man fast nie: Bitte macht es schnell“ war in fast jeder Firma, in der ich gearbeitet habe, Seitengeschwindigkeit und Latenz eine Top-Priorität. Ob Startup oder Konzern: Geschwindigkeit und Latenz waren wichtige Ziele, und es wurde fast immer genau darauf geachtet, wie schnell das Produkt ist, wie schnell Seiten laden und ob es merkwürdige Verzögerungen gibt.
  • In den meisten Firmen, die ich selbst erlebt habe (6 von 8), bekam man fast nie Zeit für Performance-Optimierung, sodass ich sie immer heimlich nebenbei machen musste. Selbst dort, wo man Latenz misst und ihre Wichtigkeit betont, wurde sie in der Praxis oft von Feature-Arbeit verdrängt.
  • Ich habe oft erlebt, dass Leute die Suchgeschwindigkeit obsessiv optimieren, sich aber kaum darum kümmern, wie schnell die Seite gerendert wird oder wie groß die Datenmenge ist, die zum Nutzer geschickt wird.
• Etwas, das ich in vielen Jobs immer wieder erlebt habe: Die meisten unterschätzen den echten Wert von Geschwindigkeit. Sie nehmen einfach an, dass „derselbe Workflow, nur schneller“ dabei herauskommt. Zum Beispiel denkt man oft, dass es wenig bringt, ein großes Experiment zu beschleunigen, das ohnehin über Nacht läuft. Wenn man die Geschwindigkeit aber drastisch erhöht, kann man dasselbe Experiment tagsüber mehrfach laufen lassen — und plötzlich entsteht eine völlig andere Größenordnung an Produktivität.
  • Die Kosten von Context Switching werden massiv unterschätzt. Wenn ein Befehl statt 30 nur noch 3 Sekunden braucht, denken viele: Bei 10 Mal am Tag spart man eben 5 Minuten. Aber die eigentlichen Umschaltkosten sind viel höher.
  • Jedes Mal, wenn eine CI-Pipeline mehrere Stunden dauert, denke ich: Wenn sie in unter 20 Minuten fertig wäre, hätte ich auch die kleinen Lint-Warnungen jedes Mal gleich mit behoben.