"Schulden" gehört zu den schmutzigsten Wörtern der (Tech-)Welt. Die bloße Erwähnung ruft bereits das Gefühl von Belastung und Stress hervor. Schulden loszuwerden, gilt vor allem als lästige Pflicht. Bezogen auf die Softwareentwicklung bezeichnet der Begriff Technical Debt im Allgemeinen ein veraltetes System, das wertvolle Zeit und Ressourcen frisst. Technische Schulden müssen gemanagt, gewartet und minimiert werden und sind in der Regel der letzte Punkt auf dem Backlog. Zudem haben sie das Potenzial, Untergangsszenarien zu eröffnen.

Aber muss das wirklich so sein? Immer mehr fortschrittliche Unternehmen kommen zu der Überzeugung, dass Technical Debt zu einem zentralen Bestandteil der Softwareentwicklung werden sollte und die Developer-Teams durch deren proaktives Management nicht nur Untergangsszenarien vermeiden, sondern sogar Wettbewerbsvorteile erzielen können.

Technische Schulden im Wandel der Zeit

Ursprünglich wurde der Begriff Technical Debt im Jahr 1992 vom Informatiker Ward Cunningham geprägt. Die Idee dahinter: Der Einsatz kurzfristiger Lösungen für technische Systeme bringt eine Reihe von Kompromissen mit sich, die zu künftigen Verpflichtungen führen und in Form von technischer Arbeit zurückgezahlt werden müssen. Der Softwareentwickler Martin Fowler beschrieb Technische Schulden im Jahr 2003 folgendermaßen: "In dieser Metapher führt ein 'Quick and Dirty'-Ansatz zu einer technischen Schuld. Diese ist mit einer finanziellen Schuld vergleichbar und führt ebenfalls zu Zinszahlungen, die in Form von zusätzlichem Aufwand für die zukünftige Entwicklung anfallen."

Lesen Sie auch: So gehen Unternehmen am besten mit Technischen Schulden um

Der Stripe-Report "The Developer Coefficient" (PDF) aus dem Jahr 2018 kommt zum Ergebnis, dass ein Softwareentwickler im Schnitt mehr als 13 Stunden pro Woche damit verbringt, sich um technische Schulden zu kümmern. Da die Anwendungen immer komplexer werden, ist das Management von Technical Debt heute wichtiger denn je: "Jeder Code, den Sie als Verbindlichkeit eingestuft haben, ist technische Schuld", meint Alexandre Omeyer, CEO von Stepsize.

Dabei können Technische Schulden sehr unterschiedliche Ausformungen annehmen. "Am unteren Ende der Skala kann es sich um Codefragmente handeln, die refaktoriert werden müssen oder um zu korrigierende Unit-Tests", schreibt InfoWorld-Kolumnist Isaac Sacolick. "Am oberen Ende der Skala kann zum Beispiel auch das Reengineering komplexer monolithischer Anwendungen, die Portierung veralteter Webservice-Protokolle, die Konsolidierung mehrerer Plattformen auf einen Standard oder die Modernisierung der Infrastruktur unter Technische Schulden fallen. Die schlimmste Art von Technical Debt ist eine 'Burning Platform', die das Business mit wiederkehrenden Ausfällen und Vorfällen beeinträchtigt."

Auch wenn die Arbeit an einer solchen Plattform weniger verlockend ist, als tolle neue Funktionen bereitzustellen: Nur wenn Entwickler Technische Schulden proaktiv und kontinuierlich im Team angehen, lassen sich langfristige Pain Points verhindern. "Mit technischen Schulden umzugehen kommt oft zu kurz, da das selten einen dringenden Geschäftsbedarf bedient, der ROI unklar ist und die Aufgabe deshalb als aufschiebbar angesehen wird. Das ist ein klassisches Wartungsproblem, egal ob es sich um Programmcode oder ein Eigenheim handelt", schreibt Sacolick.

Für viele Entwicklungsteams - vor allem in schnell wachsenden Unternehmen - stehen Technische Schulden in einem Spannungsverhältnis zur "wichtigen" Arbeit, nämlich neue Funktionen zu entwickeln. Um sicherzustellen, dass technische Schulden ernst genommen werden, muss ein kultureller Wandel in der gesamten Organisation stattfinden.

"Einen Backlog zu haben, der nach Prioritäten geordnet ist, stellt für viele Unternehmen eine Herausforderung dar. Vor allem für solche, die an einem Punkt angelangt sind, an dem zwar Anreize bestehen, neue Dinge zu liefern, aber keine spezifischen, leistungsbasierten, um gleichzeitig ihre technischen Schulden zu managen", meint RedMonk-Analystin Rachel Stephens. Oder, wie Mik Kersten, Buchautor und Gründer von Tasktop es ausdrückt: "Wenn man nur Anreize für Funktionen schafft, begibt man sich in eine Todesspirale der technischen Schulden."

Technical Debt in den Griff bekommen

"Technische Schulden sind in der Softwareentwicklung unvermeidbar", meint John Kodumal, CTO und Mitbegründer von LaunchDarkly. Dennoch sei es wesentlich gesünder, die Schulden im Laufe der Zeit proaktiv zu reduzieren, als andere Arbeiten zu stoppen und zu versuchen, sich aus einem Technical-Debt-Berg herauszuwinden. Eine solche proaktive Herangehensweise beinhalte, alle Dinge, die als Technische Schulden durchgehen, als ein weiteres Feature zu betrachten, das in den normalen, agilen Entwicklungsprozess einbezogen werden muss.

"Um Legacy-Status zu vermeiden oder zumindest zu verzögern, müssen Richtlinien, Konventionen und Prozesse etabliert werden, um die Kosten für den Schuldenabbau im Laufe der Zeit zu amortisieren", schreibt Sacolick. Viele Teams werden versucht sein, eine bestimmte Kapazität für die Beseitigung technischer Schulden einzuplanen, beispielsweise 20 Prozent eines jeden Sprints. Tasktop-Gründer Kersten rät hingegen zu einem dynamischen Ansatz, der anstehende Deadlines oder Teamkapazitäten berücksichtigt: "Sie sollten das Geschäftsergebnis und die Investition in Technische Schulden messen und sicherstellen, dass sich diese ausgleichen. Machen Sie Technische Schulden sichtbar, damit Sie immer wissen, wie viel Sie managen. Sobald ein Überblick vorhanden ist, sollten Sie einen Zielprozentsatz festlegen, der im Laufe der Zeit dynamisch sein muss."

Für Ben Kus, CTO von Box, ist der Abbau technischer Schulden ein Punkt, den alle Entwicklungsteams in ihren Backlog aufnehmen sollten: "Natürlich wird das immer wieder aufgeschoben, aber es sollte ein Bewusstsein darüber herrschen, dass Techincal Debt kontinuierlich in Angriff genommen werden muss." Der Manager empfiehlt jedoch nicht,diese vermeintlich undankbare Aufgabe bestimmten Ingenieuren zuzuweisen: "Das könnte einen Grund für Fluktuation liefern. Niemand beschäftigt sich gerne mit Tasks wie Technischen Schulden oder Refactoring." Bei Box setze man stattdessen darauf, die Arbeit gleichmäßig auf die Entwicklungsteams aufzuteilen und Probleme während des Sprint-Prozesses, in Postmortems und auf Zuruf anzugehen, erklärt Kus.

Das Element der Rufbereitschaft wird immer wichtiger, da die Ingenieurteams versuchen, die technischen Schulden, die sie ausbremsen, effektiv zu ermitteln und zu messen. Engineering Manager wie Charity Majors, CTO und Mitbegründer von Honeycomb, sind Befürworter des Ansatzes, regelmäßig Softwareingenieure abzuberufen, um sich darauf zu konzentrieren, Technische Schulden zu beheben, umzugestalten und zu automatisieren: "Es ist wichtig, einen Ingenieur zu haben, der hauptsächlich für die kleinen Dinge verantwortlich ist. Und als Teil der Rufbereitschaft sollten diese Mitarbeiter aktiv von der Produktarbeit befreit werden. Das bringt Flexibilität in ein System, das normalerweise eher starr ist."

"Indem wir die operative Verantwortung für unsere Arbeit übernehmen, straffen wir die Rückkopplungsschleifen zwischen Shipping und Running. Dies hilft uns, pragmatische technische Entscheidungen zu treffen und ein gesundes Verhältnis zu schaffen zwischen der Auslieferung von neuem Code und der Unterstützung und Verbesserung des bestehenden", schreibt Chris Evans, Gründer des Software-Startups Incident.io, in einem Blogbeitrag. Erfolge im Bereich Technische Schulden sollten dann auch genauso gefeiert werden wie die Behebung eines größeren Problems oder die Einführung einer coolen, neuen Funktion.

Technical Debt bei der Financial Times

Die Financial Times hat die vergangenen sechs Jahre damit verbracht, ihre Herangehensweise im Bereich Technische Schulden neu zu gestalten. Im Jahr 2015 lief die Website der renommierten Zeitung über eine monolithische App namens Falcon. Im Jahr 2016 wandelten die Inhouse-Entwickler die Applikation in eine Reihe von Microservices um. Die daraus entstandenen 332 Code-Repositories, werden von einer Reihe von Teams mit definierten Verantwortlichkeiten gemanagt.

"Nach etwa einem Jahr liefen die Dinge nicht mehr so gut", verrät Anna Shipman, technische Direktorin für Kundenprodukte bei der Financial Times. Die Teams hatten den Überblick über die gesamte technische Strategie verloren und wussten nicht mehr, wer für welche Dienste zuständig war. Dies führte zu einem wachsenden Berg Technischer Schulden, verwaisten Codebasen, die niemand mehr anfassen wollte und einem schrumpfenden Pool von Ingenieuren, die noch dazu bereit waren, außerhalb der Geschäftszeiten auf Abruf bereitzustehen.

Um dieses Problem zu lösen, musste bewusst Ordnung geschaffen und die Komplexität akzeptiert werden. Erst nachdem die Teams die Verantwortung für ihre Technologie-Stacks übernommen hatten, konnte das Unternehmen damit beginnen, das Thema Technical Debt bewusster anzugehen. "Das ist nichts, was man neben der regulären Bereitstellung von Funktionen erledigt. Dafür muss man Zeit einplanen. Es reicht nicht aus, ein bisschen aufzuräumen und schon ist alles in Ordnung", erklärt Shipman.

Auch wenn es keine zentrale Vorgabe gebe (beispielsweise 20 Prozent der gesamten Entwicklungszeit für die Verwaltung Technischer Schulden zu verwenden), glaubt die Managerin, dass die Teams jetzt besser in der Lage sind, ein Gleichgewicht zwischen der Bereitstellung von Funktionen und Technischen Schulden zu finden.

Technische Schulden meets Geschäftsleitung

Sobald Sie Ihr Verhältnis zu Technischen Schulden in der gesamten Entwicklung neu bewertet haben und die Entwickler den Wert einer "Verlangsamung" verstehen, ist die Herausforderung nicht beendet: Nun gilt es, diesen Wert dem Senior Management zu vermitteln. "Produkt- und Entwicklungsmanager verwenden ihre Zeit darauf, den Geschäftswert zu steigern, so als ob mehr Schnickschnack der einzige Wert wäre. Manchmal manifestiert sich dieser aber darin, das Gesamtkonstrukt auf Vordermann zu bringen", meint Majors. Technische Schulden zu beseitigen sei oft das erste "Opfer" auf dem Weg zur Erfüllung von Geschäftszielen - eine Sichtweise, die Manager dringend ablegen müssten.

"Eine der häufigsten Beschwerden, die ich höre, wenn ich mit Ingenieuren spreche, ist, dass sie das Gefühl haben, ständig an neuen Funktionen arbeiten zu müssen, während die Software und die Tools, mit denen sie arbeiten, immer brüchiger, inkonsistenter und frustrierender werden und es für sie immer schwieriger wird, ihre Arbeit zu erledigen", schreibt David Van Couvering, Senior Principal Architect bei eBay, in einem Blogpost.

Um der Unternehmensleitung die Risiken brüchiger Systeme zu verdeutlichen, müsse man ihre Sprache sprechen und betonen, wie die Beseitigung von Technical Debt den Entwicklern ermöglicht, in Zukunft schneller voranzukommen und Software sicherer zu gestalten. Davon abgesehen könne das auch dazu beitragen, begehrte Fachkräfte davon abzuhalten, das Unternehmen zu verlassen. "Wenn Sie lernen, wie ein Anzugträger zu sprechen, profitieren Ihr Unternehmen, Ihr Team und Ihre Karriere davon. Ihr Unternehmen profitiert davon, weil es die Fehler vermeidet, die durch die Anhäufung von technischer Arbeit entstehen können", so Van Couvering.

"Erzählen Sie eine Geschichte, in der Ihr Geschäftspartner der Held ist und Sie der vertrauenswürdige Leader. Sie müssen sich an Geschäftskennzahlen wie Durchlaufzeit, Leistung und Qualität orientieren", rät Shipman von der Financial Times.

Technische Schulden erfolgreich zu managen, erfordert große Anstrengungen, um tief verwurzelte Kulturen und Arbeitsweisen zu ändern und die Kommunikation zwischen den Entwicklern und dem gesamten Unternehmen zu verbessern. Die Anreize, auf die die Entwickler hinarbeiten, müssen sich möglicherweise ändern, aber die Risiken, die sich aus wachsenden, technischen Schulden ergeben, sind potenziell existenziell.

"Ihr Argument gegen technische Schulden wird gestärkt, wenn Sie sich darauf konzentrieren, Ihrem Gegenüber zu verdeutlichen, wie heutige Entscheidungen das zukünftige Risiko erhöhen. Sprechen Sie über den Verlust der Vorhersehbarkeit im Projekt. Zeigen Sie, wie Kompromisse jetzt zu einer späteren Leistungsverschlechterung führen", schreibt RedMonk-Analystin Rachel Stephens.

Ja, neue Funktionen mit "Fancy-Faktor" halten Kunden und Führungskräfte bei Laune, aber technisch verschuldete Systeme können ganze Unternehmen ins Wanken bringen - und aus den Trümmern herauszuklettern, macht keinen Spaß. (fm)

Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation Infoworld.