Warum technische Schulden nicht mit finanziellen Schulden vergleichbar sind

Technische Schulden sind Investitionen in die Zukunft

Jan Weddehage

© Shutterstock / Tashatuvango

Aufgrund der Innovationsgeschwindigkeit in der Softwareentwicklung können technische Schulden kaum vermieden werden. Ständig müssen neue Features implementiert und Bugs gefixt werden. Damit das Ganze nicht in einer Katastrophe endet, hat sich die Auffassung durchgesetzt, dass es am besten ist, die Schulden gering zu halten und sie kontinuierlich abzutragen. Aber ist es überhaupt sinnvoll, technische Schulden wie finanzielle Schulden zu behandeln?

Technische Schulden lassen Softwareprojekte nicht auf Anhieb komplett zusammenbrechen. Unter diesem Begriff werden vielmehr vernachlässigbare Bugs, schnelle Reparaturen sowie unelegante Abkürzungen und Implementierungen zusammengefasst, die sich erst im Laufe der Zeit zu Problemen entwickeln. Technische Schulden sind meistens kleine Unachtsamkeiten und Konventionsabweichungen, die langfristig dazu führen, dass der Code aufgrund von Komplexität und Instabilität schlecht pflegbar wird. Auswirkungen hat das zumeist auf die Architektur, die Performance und die Security-Standards.

Nicht nur eine Frage der Zeit

Häufig werden enge Zeitplanungen und unrealistische Release-Termine als Gründe für die Entstehung technischer Schulden angeführt. Leittragende sind insbesondere Entwickler, die in ein laufendes Projekt einsteigen und noch nicht mit den Besonderheiten vertraut sind. Aber auch bei ausreichend Zeit können sich technische Schulden einschleichen. Etwa dann, wenn die Developer im Laufe der Zeit realisieren, wie die von ihnen implementierten Features noch besser umgesetzt werden können. Bei dieser Sorte von Schulden handelt es sich nicht um Bugs oder Abweichungen vom Standard. Vielmehr steht das grundsätzliche Design infrage. Solche Entscheidungen können im Nachhinein lediglich schwer und mit viel Zeitaufwand behoben werden.

Technische Schulden gering halten und kontinuierlich abtragen

Technische Schulden können nicht allein auf ein falsches Zeitmanagement zurückgeführt werden. Allgemein gilt aber: Je mehr technische Schulden angesammelt werden, desto größer wird der Aufwand, sie am Ende zu beheben. Wird etwas ständig auf morgen verschoben, kann das schlimmstenfalls dazu führen, dass die Entwickler letztlich bloß noch Altlasten reparieren und keine neuen Features mehr implementieren. Das kostet nicht nur Geld und Zeit, sondern wirkt sich auch negativ auf die Motivation aus.

Aus diesem Grund haben sich verschiedene Methoden und Strategien etabliert, um mit technischen Schulden umzugehen. Dr. Carola Lilienthal macht beispielsweise mit Verweis auf die kognitive Psychologie deutlich, wie wichtig eine übersichtliche Architektur bei der Vermeidung technischer Schulden ist. Die Konstruktion der Softwarearchitektur nach konsistenten und logisch aufeinander aufbauenden Einheiten hilft Developern dabei, sich die Codestruktur leichter einzuprägen. Ein Chaos bei der Implementierung neuer Features kann so verhindert werden.

Ferner fördert das Arbeiten mit verständlichen Spezifikationen in großen Teams mit verteilten Aufgaben die Kommunikation und Kollaboration. Der regelmäßige Austausch zwischen den Kollegen wirkt sich positiv auf das kollektive Wissen aus. Auf diese Weise können bereits in der grundsätzlichen Entwicklungsphase die Schulden so niedrig wie möglich gehalten werden.

Die richtige Herangehensweise an technische Schulden?

In der Softwareentwicklung sind technische Schulden also eng verbunden mit negativen Konsequenzen, die aus einer schlechten technischen Umsetzung resultieren. Ihre Behebung geht mit einem gewissen Mehraufwand einher, der größer wird, je länger man die Fehlerbeseitigung hinauszögert. Folglich beschleunigt das Aufschieben von Maßnahmen zur Sicherung und Erhöhung der technischen Qualität die Entwicklung nicht, sondern verlangsamt sie – und genau das soll der Begriff vermitteln.

In seinem Artikel „Technical Debt Shouldn’t Be Handles Like Financial Debt“ vertritt Keith Gregory hingegen die These, dass die ausschließlich negative Bewertung technischer Schulden ebenfalls die Langlebigkeit eines Projekts bedrohen kann. Die aus der Finanzwelt stammende Idee, Schulden möglichst gering zu halten und sie kontinuierlich abzubezahlen, fängt seiner Meinung nach nicht das gesamte Spektrum der Softwareentwicklung ein, sondern bildet lediglich die Perspektive der Entwickler ab. Übersehen wird dabei, dass noch weitere Parteien an diesem Prozess beteiligt sind, die oftmals keinen technischen, sondern einen betriebswissenschaftlichen Hintergrund besitzen.

Technische Schulden als Investitionen

Laut Gregory verbinden die Manager und Stakeholder eines Softwareprojekts mit Schulden nicht einzig negative Aspekte. Sie sehen in ihnen vielmehr Investitionen in die Zukunft. Verspricht die Aufnahme von Schulden langfristig einen höheren Umsatz, sollte das Risiko in Kauf genommen werden. Beide Berufsgruppen haben ihre ganz eigenen Vorstellungen davon, was es heißt, Schulden zu machen.

Schlimmstenfalls kann das dazu führen, dass die beteiligten Parteien bei Strategieentscheidungen nicht die „gleiche Sprache“ sprechen und die Langlebigkeit eines Projekts unnötig gefährden. So mag die Verschiebung des Release-Termins aufgrund anfallender technischer Schulden aus Entwicklerperspektive Sinn ergeben. Ohne Risikoanalyse führt diese Rechtfertigung bei Managern und Stakeholdern bloß zu unverständlichen Kopfschütteln.

Gregory schlägt deshalb vor, den Begriff technischer Schulden durch das, seiner Meinung nach bessere, Konzept eines „total cost of ownership“ (TCO) zu ersetzen. Unter TCO versteht er die Aufstellung einer Kosten-Nutzen-Analyse, die eindeutig darüber Auskunft gibt, was sowohl die aktuelle als auch die zukünftige Entwicklung von Features kostet. Ihm zufolge wird der Development-Prozess dadurch zwar nicht unbedingt vereinfacht, aber zumindest das nötige Maß an Transparenz geschaffen.

Integrieren statt entwickeln

Allerdings ist eine solche Kosten-Nutzen-Rechnung ebenfalls mit dem Konzept technischer Schulden realisierbar. Denn im Gegensatz zur Gregorys Darstellung können sich Entwickler sehr wohl für oder gegen technische Schulden entscheiden, wenn sie die Vor- und Nachteile abgewägt haben. Eine gute Methode, um auf die Bedürfnisse der Manager und Stakeholder einzugehen, gleichzeitig aber auch den Schuldenberg nicht zu stark anwachsen zu lassen, ist zum Beispiel die frühe und kontinuierliche Integration neuer Funktionen.

Man sollte sich auf die kontinuierliche Integration neuer Features, die zuvor auf ihre Komptabilität hin getestet worden sind, konzentrieren und die parallele Entwicklung auf ein Minimum zurückschrauben. Die Erstellung eines fehlerfreien Hauptzweigs und die anschließende Implementierung neuer Funktionen als eigene Projektzweige helfen dabei, die Anzahl an Fehlern und Bugs gering zu halten. So bleibt nicht nur der Code gut wartbar, es können auch die Release-Zeiten verkürzt werden. Unerlässlich ist hierfür allerdings die ausführliche Dokumentation der aufgenommenen technischen Schulden in einem Backlog. Dieses Vorgehen sorgt für die nötige Transparenz und vereinfacht sogar den Entwicklungsprozess.

Fazit

Gregorys Einwand, dass technische Schulden nicht nur negative Folgen haben, sondern ebenfalls als Investitionen in die Zukunft gewertet werden können, ist richtig. Wenn von technischen Schulden in der Softwareentwicklung gesprochen wird, sollten nicht ausschließlich die Meinungen der Entwickler, sondern auch die Interessen von Managern und Stakeholdern Berücksichtigung finden – und hierfür haben die Developer bereits die richtigen Tools zur Hand.

Aufmacherbild: Investments via Shutterstock / Urheberrecht: Tashatuvango

Geschrieben von
Jan Weddehage
Jan Weddehage
Jan Weddehage studiert an der Goethe Universität Frankfurt am Main und arbeitet seit März 2015 als Werkstudent bei Software & Support. Kontakt: jan[at]janweddehage.de
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: