© saicle/Shutterstock.com
Neue Betriebswirtschaftslehre für Softwareentwicklung

Schulden - weniger ist mehr


Die spektakuläre Pleite von Lehman Brothers ist nun sieben Jahre her. An der Frage, ob die Finanzwelt aus diesem Ereignis etwas gelernt hat, scheiden sich die Geister. Eine andere Frage, die mindestens ebenso spannend ist, wurde aber bislang gar nicht gestellt: Was hat die Softwareentwicklung aus der Pleite von Lehman Brothers gelernt? Eine Frage von zugegebenermaßen nicht geringer Größe, deren Antwort notwendigerweise umfangreich ausfallen muss. Als Informatiker möchte ich mich der Antwort mit einer weit verbreiteten Methode aus der Softwareentwicklung nähern: divide and conquer.

Am 29.05.2009 geschah in Deutschland etwas, das kaum ein Softwareentwickler bemerkt hat, obwohl es seine Arbeit direkt betraf [1], [2]. An diesem Tag wurde der § 248 HGB [3] geändert, sodass es ab sofort möglich war, die Aufwände für die Entwicklung von Software in einem Unternehmen als nicht materiellen Vermögensgegenstand in dessen Bilanz zu aktivieren. Auch wenn – oder gerade weil – sich nur wenige Softwareentwickler, die ich kenne, für die Feinheiten der Bilanzbuchhaltung interessieren, möchte ich kurz erläutern, was diese Änderung genau bedeutet: Kapitalgesellschaften sind verpflichtet, zweigeteilte Bilanzen zu erstellen.

Divide: Software aus Sicht des Ökonomen

Eine Seite sind die so genannten Aktiva, die andere Seite wird als Passiva bezeichnet. Historisch betrachtet stehen auf der Aktivseite Vermögensgegenstände, die liquidierbar sind, also verkauft werden können. Die Passivseite beinhaltet im Wesentlichen Kapitalpositionen wie die Einlagen der Gesellschafter oder Kredite, die das Unternehmen aufgenommen hat. Eine solche Bilanz ist ein Aspekt, wenn es darum geht, Unternehmen zu bewerten.

Eine sehr einfache, wenn auch naive Betrachtung der Bilanz kann sein, dass ein Unternehmen mit hohen Werten auf der Aktivseite ein großes Anlagevermögen besitzt, sowohl an materiellen Gütern als auch an immateriellen Vermögensgegenständen. Software, die den Regeln des § 248 HGB genügt, ist ein solcher immaterieller Vermögensgegenstand.

Aus Sicht des Ökonomen ist eine Software – aus der Perspektive der Bilanz – also besonders wertvoll, wenn ihre Erstellung teuer war, was im Sinne dieses Paragraphen gleichbedeutend damit ist, dass viel Aufwand geleistet wurde, um sie zu erstellen. Das ist natürlich nur eine vereinfachte Darstellung. Aber da die Aufwandsbewertung in der Praxis durchaus angewendet wird, möchte ich sie nutzen, um die Gefahr einer solchen Bewertung von Software zu zeigen.

Divide: Technische Schulden und Aufwand

Fragt man Softwareentwickler danach, was technische Schulden sind, bekommt man viele verschiedene Erklärungen. Eine wissenschaftliche oder formale Definition gibt es bisher nicht. Zuerst wurde der Begriff von Ward Cunningham [4] verwendet, um den Zusammenhang zwischen Entscheidungen während der Softwareentwicklung und den ökonomischen Auswirkungen auf die Software für Nicht-Softwareentwickler deutlich zu machen.

Die Definition des Begriffs umfasst je nach Umfeld das Nichtdurchführen oder Aufschieben bestimmter Handlungen, wie das Erstellen von Dokumentation oder Tests oder Investitionen in Infrastruktur. Oft werden aber auch die Verwendung von Antipatterns, ein schlechter Programmierstil oder das Ignorieren von Coding-Standards als technische Schuld betrachtet. Zu komplizierte Lösungen, wie sie hin und wieder durch Overengineering entstehen, und Softwareerosion werden ab und an ebenfalls zu den technischen Schulden gezählt.

Neben allen diesen verschiedenen Definitionen zur Natur technischer Schulden ist es interessant, dass ihre Wirkung sehr gleichförmig ist: Technische Schulden wirken primär als Aufwandstreiber. Es ist aufwändiger, eine Software weiterzuentwickeln, die technische Schulden beinhaltet, als eine Software ohne solche. Und je länger die technischen Schulden bestehen, desto stärker wirken sie sich aus. An dieser Stelle gibt es also durchaus eine Äquivalenz zwischen finanziellen Schulden, die sich durch Zinsen vermehren, und den technischen Schulden, deren Beseitigung immer aufwändiger und damit teurer wird.

Nun kann aber Software betriebswirtschaftlich nach dem Aufwand ihrer Erstellung bewertet werden. Eine Software mit hohem Erstellungsaufwand ist in dieser Betrachtung wertvoller, weil teurer, als eine Software mit niedrigem Erstellungsaufwand. Ein Schelm, wer nun auf die Idee komm...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang