Warum gute Software Zeit braucht und Geduld verlangt

Flask brauchte acht Jahre bis zur Version 1.0. SQLite wird seit 2000 aktiv entwickelt und bekommt immer noch spürbare Verbesserungen. Der Linux-Kernel ist über drei Jahrzehnte alt und wird wohl mit dem Alter besser. Derweil muss ein durchschnittliches VC-finanziertes Startup innerhalb von 18 Monaten Traktion zeigen – oder erklären, warum nicht.

Zwischen der Zeit, die gute Software tatsächlich zum Bauen braucht, und der Zeit, die wir erwarten, klafft eine wachsende Lücke. Der Druck, schnell auszuliefern, ist an sich nicht falsch – aber er erzeugt eine Kultur, in der Geduld als fehlender Ehrgeiz gilt und in der die Projekte, die Bestand haben, in den Jahren, in denen sie still die Dinge richtig machen, als „langsam“ abgetan werden.

Der Mythos vom Overnight-Erfolg

Fast jeder „Overnight-Erfolg“ in der Softwarewelt hat eine lange Vorgeschichte. React wurde bei Facebook über ein Jahr intern genutzt, bevor es Open Source wurde. Rust war sieben Jahre in Entwicklung, bevor Version 1.0 erschien. PostgreSQL begann 1986 als Forschungsprojekt und wurde erst in den 2010er-Jahren zur Standarddatenbank für den Produktivbetrieb – fast 30 Jahre stetiger, stiller Verbesserung.

Was wie ein plötzliches Auftauchen aussieht, ist meist das Ergebnis sich aufsummierender Verbesserungen, die irgendwann eine Sichtbarkeitsschwelle überschreiten. Die Software wurde die ganze Zeit besser. Die Leute haben nur nicht hingesehen, bis sie gut genug war, um nicht mehr zu übersehen.

Armin Ronacher, der Erfinder von Flask, hat genau darüber geschrieben. Flask begann 2010 als Aprilscherz. Daraus wurde fast zufällig ein ernsthaftes Projekt. Jahre inkrementeller Arbeit – Randfälle beheben, Dokumentation verbessern, APIs überdenken – machten es zu einem der beliebtesten Python-Web-Frameworks. Keines dieser Jahre war verschwendet. Jedes hat das Fundament stabiler gemacht.

Warum Software einen nicht reduzierbaren Zeitfaktor hat

Manche Probleme lassen sich nicht schneller lösen, indem man mehr Leute einstellt oder härter arbeitet. Fred Brooks hat das 1975 mit The Mythical Man-Month beschrieben, und die Kernaussage gilt noch immer: Bestimmte Aspekte der Softwareentwicklung sind sequenziell und nicht parallelisierbar.

• Das Problemfeld verstehen. Einen Problemraum wirklich zu verstehen, geht erst, wenn man eine Weile darin gelebt hat. Die erste Version jeder Software verkörpert deine anfänglichen Annahmen. Die zweite Version enthält, was du aus der ersten gelernt hast. Echtes Verständnis braucht Iterationen, und Iterationen brauchen Zeit.
• API-Design und Stabilität. Gute APIs entstehen durch Nutzung. Man kann keine perfekte API im luftleeren Raum entwerfen – man braucht echte Nutzer, die echte Randfälle treffen. Bibliotheken, die sich zu früh auf 1.0 festlegen, bereuen ihre frühen Designentscheidungen oft jahrelang.
• Randfälle und Härtung. Die ersten 80 % einer Funktion kosten 20 % der Zeit. Die restlichen Randfälle, Fehlerbehandlung und Plattform-Eigenheiten kosten die anderen 80 %. Dieses Verhältnis ist keine Faulheit – es ist die grundlegende Natur davon, Software zuverlässig zu machen.
• Community und Ökosystem. Ein Tool ist erst wirklich nützlich, wenn es Dokumentation, Tutorials, Plugins und eine Community gibt, die Fragen beantwortet. Dieses Ökosystem lässt sich nicht herstellen; es wächst organisch über die Zeit.

Der Schaden durch künstliche Dringlichkeit

„Move fast and break things“ war ein vernünftiges Motto für ein soziales Netzwerk, das Product-Market-Fit suchte. Für Infrastruktur, Entwicklerwerkzeuge, Datenbanken oder alles, wovon die Systeme anderer abhängen, ist es eine schlechte Philosophie. Wenn man Fundamentsoftware überstürzt, summieren sich die Brüche.

Ich habe zugesehen, wie mehrere vielversprechende Open-Source-Projekte implodiert sind, weil sie schneller wachsen wollten, als ihr Fundament tragen konnte. Das Muster ist vorhersehbar: Ein Projekt wird populär, die Maintainer spüren den Druck, schnell Features zu liefern, die Qualität sinkt, Contributors brennen aus, und Nutzer wandern zu etwas Stabilerem ab. Das Ironische: Langsamer zu werden hätte sie weiter gebracht.

Die Projekte, die bleiben, sind nicht die, die am schnellsten ausgeliefert haben. Es sind die, die früh genug gute Entscheidungen getroffen haben, sodass sie später nicht alles neu schreiben mussten.

Technische Schulden sind nicht nur unordentlicher Code. Sie entstehen aus Entscheidungen unter Zeitdruck, die künftige Möglichkeiten einschränken. Jede Abkürzung, die dich schneller ans Ziel bringt, ist eine Steuer auf jede zukünftige Änderung. Manche Abkürzungen sind es wert – aber man sollte sie bewusst nehmen und nicht, weil jemand willkürlich entschieden hat, dass die Deadline nächsten Dienstag ist.

Wie Geduld in der Praxis aussieht

Geduld in der Softwareentwicklung heißt nicht, um des Langsamseins willen langsam zu arbeiten. Es heißt, bewusst zu entscheiden, was man baut, und ehrlich zu sein, wie lange Dinge dauern. Ein paar Muster, die ich gut funktionieren sehe:

• Früh ausliefern, aber langsam festlegen. Veröffentliche deine Software früh, damit du Feedback bekommst, aber sei sehr zurückhaltend damit, was du als stabile API zusagst. Nutze großzügig die 0.x-Versionierung. Mach deutlich, dass sich Dinge noch ändern können.
• Nein zu Features sagen. Jedes Feature, das du hinzufügst, musst du für immer pflegen. Die besten Projekte sind klar in ihrem Umfang. SQLite listet ausdrücklich auf, was es niemals tun wird – und genau diese Disziplin macht es zur am weitesten verbreiteten Datenbank der Welt.
• In Grundlagen investieren. Dokumentation, Tests, Fehlermeldungen, Performance – das ist nicht glamourös, aber es summiert sich. Ein gut dokumentiertes Projekt mit solider Testsuite kann im dritten Jahr schneller vorankommen als ein schlecht dokumentiertes im ersten.
• Die Energie der Maintainer schützen. Burnout ist der größte Killer von Open-Source-Projekten. Nachhaltiges Tempo zählt mehr als Sprint-Velocity. Ein Maintainer, der fünf Jahre lang 20 konzentrierte Stunden pro Woche arbeitet, liefert mehr als einer, der sechs Monate lang 80 Stunden pro Woche arbeitet und dann verschwindet.

Die Geschwindigkeitsfalle bei Startups

Startups stehen vor einem echten Spannungsfeld: Sie müssen schnell sein, um zu überleben, aber zu schnelles Vorgehen erzeugt fragile Systeme, die beim Skalieren zur Belastung werden. Die Firmen, die das gut meistern, unterscheiden meist zwei Arten von Geschwindigkeit.

Iterationsgeschwindigkeit – wie schnell du Ideen testen, Nutzerfeedback einholen und die Richtung ändern kannst. Diese sollte maximiert werden. Kurze Zyklen, schnelles Prototyping, die Bereitschaft, Dinge wegzuwerfen.

Verbindlichkeitsgeschwindigkeit – wie schnell du dich auf Architekturentscheidungen, öffentliche APIs und Datenmodelle festlegst. Diese sollte minimiert werden. Halte Dinge so lange wie möglich umkehrbar. Je länger du unumkehrbare Entscheidungen aufschieben kannst, desto mehr Informationen hast du, wenn du sie schließlich triffst.

Der Fehler, den die meisten Startups machen, ist, beides gleichzusetzen. Sie legen sich auf Architekturen so schnell fest, wie sie Features iterieren, und zahlen dann die nächsten zwei Jahre die Steuer für voreilige Entscheidungen.

Was man von Projekten lernen kann, die überdauert haben

Die Softwareprojekte, auf die wir uns am meisten verlassen, haben einen gemeinsamen Zug: Irgendwann galten sie alle als „langsam“. PostgreSQL war die langweilige Wahl, während MySQL die schnelle und lockere Option war. Python galt als „zu langsam“, während Perl die pragmatische Wahl war. Git brauchte Jahre, bis normale Menschen es benutzen konnten.

Was diese Projekte hatten, war Zeit – Zeit, Fehler zu machen, daraus zu lernen und etwas Solides zu bauen. Sie wollten im ersten Jahr nicht allen alles recht machen. Sie wollten in ihrem Kernzweck exzellent sein, und sie waren bereit, dass diese Exzellenz so lange dauert, wie sie braucht.

Wenn dich das nächste Mal ärgert, dass ein Projekt „zu lange braucht“, bedenke: Die Dinge, auf die du dich am meisten verlässt – dein Betriebssystem, deine Datenbank, deine Laufzeitumgebung, deine Versionsverwaltung – haben alle länger gedauert, als irgendjemand erwartet hat. Und genau deshalb funktionieren sie.

Manche Dinge brauchen einfach Zeit. Die beste Reaktion ist nicht, gegen diese Realität anzukämpfen, sondern Systeme, Teams und Erwartungen zu bauen, die sie einkalkulieren.