Wächst Software analog zu dem für Prozessoren geltenden mooreschen Gesetz? Les Hatton, Diomidis Spinellis und Michiel van Genuchten haben hierzu im vergangenen Jahr eine interessante Studie (1) im Journal of Software veröffentlicht, welche wir hier vorstellen. Das Ergebnis lautet übrigens tatsächlich 42.

...

Inhalt

Hintergrund

Vereinfacht ausgedrückt, besagt das mooresche Gesetz, dass sich die Leistungsfähigkeit von Computer-Prozessoren etwa alle 18 Monate verdoppelt. Leistungsfähigkeit wird hierbei mit der Anzahl von Transistoren gleichgesetzt, was zwar eben eine Vereinfachung ist, aber eine allgemein akzeptierte. Das »Gesetz« ist auch eher als Faustformel zu verstehen, welche aber empirisch belegt ist.

Für Software fehlte so eine allgemein anerkannte Faustformel bislang, wie beispielsweise auch die New York Times feststellte:

»There are no such laws in software.«

Gegenfalls wäre hier das Wirthsche Gesetz anzuführen, welches aber nur recht allgemein feststellt, dass »die Software schneller langsamer wird, als die Hardware schneller wird«. Demgegenüber stellte Marc Andreessen aber fest: »Software is eating the world«.

Wie soll aber die Leistungsfähigkeit von Software beurteilt werden? Vielleicht durch die Anzahl ihrer Features? Dann stellt sich gleich die Frage, wie man Features misst und vergleicht, womit man zu aufwendigen Verfahren, wie etwa der Function Point Analyse kommt. Nach unserer Erfahrung wird selbige nur selten eingesetzt, weshalb sie sich für einen empirischen Nachweis vermutlich nicht eignet. Natürlich ist Softwareentwicklung komplex und lässt sich nur schwerlich auf eine einfache Metrik reduzieren, aber vielleicht ist eine Vereinfachung analog zum mooreschen Gesetz der Hardware auch für die Software eine Lösung.

Michiel van Genuchten und Les Hatton zeigten einen entsprechenden Ansatz erstmals 2012 in ihrem Artikel »Compound Annual Growth Rate for Software« (2) im IEEE Software Magazine auf.

Lines of Code

Die Autoren umgehen die Frage der Leistungsfähigkeit von Software hier und messen stattdessen, wie sich die Codebasis von verschiedenen Softwaresystemen hinsichtlich ihrer Größe in Anzahl der Codezeilen (»Lines of Code« (LoC)) über die Zeit entwickeln. In Anlehnung an die Anzahl Transistoren des mooreschen Gesetz durchaus nachvollziehbar. Die zugrunde liegende Codebasis umfasste zwei Open und 6 Closed Source Systeme. Dies reichte zwar vielleicht noch nicht für eine statistisch relevante Aussage, das Ergebnis erschien mit einem Faktor von 1,16 aber schon recht stabil. Demnach verdoppelt sich Software also alle rund 5 Jahre im Umfang:

»If we don’t know anything about a certain software system at hand, as a good starting point, we could assume it has a CAGR of the median value 1.16 and therefore doubles in size every four to five years.«

Interessanterweise stellen wir bei Diskussionen um die Messgröße Lines of Code in der Softwareentwicklung häufig sehr dogmatisch ablehnende Haltungen fest, ohne dass dann aber Alternativen aufgezeigt werden können. Natürlich sind die Lines of Code eine Vereinfachung der komplexen Softwareentwicklungswelt. Aber alle Metriken sind Reduzierungen und können und wollen nicht die ganze Komplexität in einer Größe zeigen – es sind Modelle. Wenn es um Fitness oder Gesundheit geht, schauen wir uns genauso vereinfachend zunächst häufig das Gewicht in kg einer Person an. Was aber nun, wenn jemand mehr Sport macht, dabei an Muskelmasse zunimmt und entsprechend sein Gewicht erhöht; ist das jetzt gut oder schlecht? Auch hier reicht das eindimensionale Körpergewicht in kg einer Person als Kennzahl alleine nicht mehr aus, ist aber ein guter Einstieg in die Diskussion und weitere Analyse. Genauso sollten wir es mit der Kennzahl LoC in der Softwareentwicklung halten.

Compound Annual Growth Rate

Die Compound Annual Growth Rate (CAGR) oder jährliche Wachstumsrate ist eine »in der Betriebswirtschaft und Volkswirtschaft […] wesentliche Kennziffer«. Sie ist insbesondere im Finanzsektor etabliert, um zum Beispiel das komplexe Wachstumsverhalten von Finanzinstrumenten abzubilden. Da die CAGR auch Eigenschaften aufweist, die für das komplexe Verhalten von Software relevant sind, spricht vieles dafür, sie entsprechend zu übernehmen:

»Sie stellt das durchschnittliche jährliche Wachstum einer zu betrachtenden Größe dar. […] Tatsächliche Ausschläge der Folgejahre in der Zwischenzeit wirken sich dabei nicht aus, die Wachstumsrate ist konstant.«

Auf Software angewandt, gleichen sich Effekte, wie zum Beispiel durch Refactoring-Maßnahmen, welche die Codebasis kurzeitig in die eine oder andere Richtung verändern können, ohne entsprechende Auswirkung auf die Funktionalität zu haben, dem folgend über die Zeit auch wieder aus.

Follow-up

Da dem eingangs erwähnten Artikel noch nicht genug statistisch relevantes Material für eine empirische Aussage zugrunde lag, haben Les Hatton und Michiel van Genuchten, diesmal erweitert um Diomidis Spinellis, 2017 »The long‐term growth rate of evolving software: Empirical results and implications« (1) veröffentlicht. Darin ermitteln sie den CAGR für über 404 Millionen Zeilen Code aus Open als auch Closed Source Software Systemen.

Mit diesem erweiterten Datensatz konnten sie eine jährliche Wachstumsrate des Quellcodes von Softwaresystemen von 1,21 ermitteln. Ohne weitere Kenntnis um ein System kann man demzufolge davon ausgehen, dass ein Softwaresystem den Umfang seines Quellcodes alle 42 Monate verdoppelt.

Interessant sind hier auch die in der Studie ausgewiesenen Unterschiede zwischen einzelnen Produkten und Branchen. Sun Solaris von Oracle und somit ein Closed Source System weist nur einen CAGR von 1,09 beziehungsweise eine Verdoppelung alle 8 Jahre auf, wohingegen der Open Source Linux Kernel auf einen CAGR von 1,32 kommt und sich somit schon nach 2,5 Jahren verdoppelt hat. Wobei die Autoren ansonsten keine Beziehung zwischen dem CAGR und der Art der Software (Open vs. Closed Source) herstellen konnten. Software im sicherheitskritischen Bereich wächst der Untersuchung zufolge mit einem CAGR für ein Flugmanagementsystem von 1,10 erheblich langsamer als beispielsweise eine Navigtionssoftware mit 1,23.

Anwendung

Software wächst. Um wie viel genau ist individuell unterschiedlich, im Schnitt kann man aber davon ausgehen, dass der Umfang an Quellcode, den man zu verwalten hat, pro Jahr um mehr als 20% zulegt. Darauf muss man sich als Entwicklungsleiter einer Softwareeinheit strukturell einstellen.

Aus der Finanzwelt weiß man, dass niemand den Markt schlägt, man sein Geld also beispielsweise besser in einen passiv gemanagten Indexfonds anlegt, anstatt es einem aktiv gemanagten Fond anzuvertrauen. Auf die Softwareentwicklung umgemünzt, empfehlen die Autoren der Studie, eine Roadmap oder einen Produktmanager, welche beispielsweise eine Verdoppelung der Software in einem Jahr nahelegen, sehr kritisch zu hinterfragen. Was genau werden wir anders machen, um soviel besser als der »Markt« zu sein?

Aus eigener Erfahrung heraus können wir auch anderherum bestätigen, dass Software wächst, zum Teil ob man nun will oder auch nicht. Wir kennen Softwaresysteme, von denen Unternehmen sich trennen wollten und daran auch mehr oder weniger aktiv gearbeitet haben und die trotzdem Jahr für Jahr weiter gewachsen sind. Um einen CAGR unter 1 zu erzielen, muss man als Entwicklungsleiter also andersherum auch die entsprechenden Voraussetzungen schaffen. Das bedeutet üblicherweise, im »Eingangskanal« nur noch die absolut notwendigen Anforderungen wie zum Beispiel gesetzliche Anpassungen durchzulassen und auf Umsetzungsseite die Kapazität zu reduzieren. Dies reicht unserer Erfahrung nach alleine aber noch nicht aus, um den CAGR unter 1 zu bringen und den Umfang eines Systems wirklich zu reduzieren. Je nach Struktur der Entwicklungsorganisation kann es beispielsweise helfen, ein dediziertes Team mit dem Abbau zu beauftragen oder aber den Abbau von Code über alle Teams hinweg zu incentivieren.

Ausblick

Moore’s Law nähert sich einem physikalischen Ende. Wie aber beispielsweise auch in dem weiter oben erwähnten Artikel der New York Times formuliert wurde, hat Software keine solchen Begrenzungen:

Software […] is pure abstraction — a building material without material constraints.

Somit ist ein Ende des Wachstums von Software nicht absehbar. Die hier vorgestellte Wachstumsrate erfasst dabei nur, wie ein einzelnes System wächst. Die Menge an Software insgesamt wird noch wesentlich stärker wachsen: »Software is eating the world«. Da Software sich absehbar auch noch selbst vervielfältigt, dürften wir vor einer Art »kambrischen Explosion der Software« stehen.

Zusammenfassung

Software wächst zwar langsamer als Hardware, aber sie verdoppelt ihren Umfang im Schnitt doch auch alle 42 Monate. Dies konnten die Autoren der Studie empirisch nachweisen. Damit haben Beteiligte der Softwareentwicklung mit dem CAGR für Software eine Fautformel an der Hand, die eine ähnliche Qualität wie das mooresche Gesetz für Hardware aufweist. Insbesondere bietet sie sich als Einstiegspunkt für Diskussionen bei individuellen Abweichungen an.

Referenzen

(1) Hatton L., Spinellis D., van Genuchten M., “The long‐term growth rate of evolving software: Empirical results and implications”, J Softw Evol Proc. 2017;29:e1847. https://doi.org/10.1002/smr.1847

(2) M. van Genuchten and L. Hatton, “Compound Annual Growth Rate for Software”, in IEEE Software, vol. 29, no. , pp. 19-21, 2012. http://doi.ieeecomputersociety.org/10.1109/MS.2012.79