Hintergrund
Jeder, der länger als ein paar Jahre in der Softwareentwicklung arbeitet, kennt das Phänomen: Systeme werden größer. Ständig. Unaufhaltsam. Was als überschaubares Projekt beginnt, wächst über die Jahre zu einer Codebasis, die niemand mehr vollständig überblickt. Neue Features kommen hinzu, alte werden selten entfernt. Konfigurationen wachsen, Testsuiten wachsen, Build-Zeiten wachsen.
Aber wie schnell wächst Software eigentlich? Gibt es ein Muster, eine Gesetzmäßigkeit — so wie Moores Law für die Verdoppelung der Transistordichte? Die Antwort ist: Ja, es gibt eine. Und sie ist bemerkenswert stabil.
Lines of Code
Bevor wir zur eigentlichen Erkenntnis kommen, ein kurzer Hinweis: Lines of Code (LoC) sind eine umstrittene Metrik. Sie messen nicht die Qualität, nicht die Komplexität und nicht den Wert von Software. Eine Zeile Code in einem sicherheitskritischen Echtzeitsystem ist nicht dasselbe wie eine Zeile Code in einem Webformular.
Trotzdem haben Lines of Code einen entscheidenden Vorteil: Sie sind objektiv messbar und über verschiedene Systeme, Sprachen und Zeiträume hinweg vergleichbar. Für die Frage, wie schnell Software wächst, sind sie die beste verfügbare Datenbasis — nicht perfekt, aber brauchbar.
Compound Annual Growth Rate
2012 veröffentlichten Michel van Genuchten und Les Hatton im IEEE Software Magazine eine bemerkenswerte Studie. Sie analysierten die Wachstumsraten von 12 großen Softwaresystemen über einen Zeitraum von mehreren Dekaden. Ihre Methode: die Compound Annual Growth Rate (CAGR) — die gleiche Kennzahl, die in der Finanzwelt für die Bewertung von langfristigem Investitionswachstum verwendet wird.
2017 legten sie mit einer erweiterten Studie nach: 404 Millionen Lines of Code aus unterschiedlichsten Domänen — von Betriebssystemen über Geschäftsanwendungen bis hin zu eingebetteter Software. Das Ergebnis war erstaunlich konsistent.
Die Parallele zu Moores Law liegt auf der Hand: Wie sich die Transistordichte auf Chips regelmäßig verdoppelt, verdoppelt sich auch der Umfang von Software in einem vorhersagbaren Rhythmus. Der Unterschied: Moores Law beschreibt einen Fortschritt in der Hardware-Effizienz. Die Verdoppelung von Software ist kein Fortschritt — sie ist eine Herausforderung.
Follow-up: Individuelle Systeme
Die durchschnittliche CAGR von 1,21 verdeckt erhebliche Unterschiede zwischen einzelnen Systemen. Die Follow-up-Studie von 2017 schlüsselte die Wachstumsraten für bekannte Systeme auf:
Sun Solaris wuchs vergleichsweise langsam — mit einer CAGR von 1,09 verdoppelte sich das System nur etwa alle acht Jahre. Der Linux Kernel dagegen wuchs mit einer CAGR von 1,32 deutlich schneller: eine Verdoppelung alle zweieinhalb Jahre.
Ein bemerkenswerter Befund der Studie: Sicherheitskritische Software wächst tendenziell langsamer als Geschäftsanwendungen. Das ergibt Sinn — in regulierten Umgebungen wird jede Codeänderung aufwendig validiert und zertifiziert, was das Wachstum natürlicherweise bremst. Gleichzeitig zeigt es, dass langsames Wachstum nicht zwangsläufig ein Zeichen von Stagnation ist, sondern von Disziplin.
Anwendung
Was bedeuten diese Zahlen für die Praxis? Drei konkrete Implikationen:
Erstens: Planen Sie mit mindestens 20 Prozent jährlichem Wachstum. Wenn Ihre Codebasis heute 500.000 Zeilen umfasst, werden es in drei Jahren voraussichtlich über 850.000 sein — und in sieben Jahren über eine Million. Build-Systeme, Testinfrastruktur, Entwickler-Tooling und Architekturentscheidungen müssen dieses Wachstum antizipieren.
Zweitens: Hinterfragen Sie aggressive Roadmaps. Wenn ein System ohnehin um 20 Prozent pro Jahr wächst, bedeutet eine ambitionierte Feature-Roadmap nicht lineares, sondern exponentielles Wachstum. Jedes neue Feature kommt nicht in ein statisches System, sondern in eines, das bereits gewachsen ist. Die Komplexitätskosten neuer Features steigen mit der Größe der bestehenden Codebasis.
Drittens: Investieren Sie in dedizierte Teardown-Teams. In vielen Organisationen gibt es Teams, die Features bauen — aber keine, die alte Features entfernen, ungenutzten Code bereinigen oder technische Schulden systematisch abbauen. Bei einer Verdoppelung alle 42 Monate ist das eine Garantie für eine Codebasis, die irgendwann unter ihrem eigenen Gewicht zusammenbricht. Dedizierte Teardown-Kapazität ist keine Kür, sondern Pflicht.
Zusammenfassung
Software wächst. Nicht zufällig, nicht unvorhersehbar, sondern mit einer bemerkenswert stabilen Rate von etwa 21 Prozent pro Jahr. Diese Erkenntnis ist weder optimistisch noch pessimistisch — sie ist eine Tatsache, mit der man planen kann.
Die CAGR von 1,21 ist das Moores Law der Softwareentwicklung: eine empirisch belegte Regelmäßigkeit, die jedem, der Software plant, entwickelt oder verantwortet, als Orientierung dienen sollte. Wer diese Wachstumsrate ignoriert, wird von ihr überrascht. Wer sie einkalkuliert, kann vorausschauend handeln — bei der Architektur, bei der Teamplanung und bei der ehrlichen Bewertung, was ein System in fünf Jahren brauchen wird.
Die Studien von van Genuchten und Hatton verdienen mehr Aufmerksamkeit, als sie bisher bekommen haben. In einer Branche, die sich gerne auf Bauchgefühl verlässt, liefern sie eine der wenigen belastbaren quantitativen Aussagen über das Wesen von Software.
Geschäftsführer
Michael Schwarze ist Geschäftsführer von atra consulting und erfahrener Softwareentwickler, -architekt und -manager mit über 30 Jahren Erfahrung. Er hat in Startups und Konzernen gearbeitet und begeistert sich für moderne Softwarearchitekturen und dynamisch-typisierte Sprachen.
