Die meisten Unternehmen betrachten ihre technischen Schulden als eine Last, die es zu bewältigen gilt. Andere haben mehr Erfolg, indem sie sie zu einem wichtigen Teil der täglichen Arbeit eines jeden Entwicklers machen. [...]
Es ist eines der unschönsten Wörter in der Tech-Branche. Genau wie im Leben ruft die bloße Erwähnung von Schulden das Gefühl hervor, belastet zu sein, unter Stress zu stehen. Und Schulden loszuwerden ist eine lästige Pflicht.
Speziell in der Softwareentwicklung beziehen sich technische Schulden im Allgemeinen auf ein System, das altert und die wertvolle Zeit der Ingenieure auffrisst. Technische Schulden sind etwas, das verwaltet, gepflegt und minimiert werden muss. Sie sind das Letzte, was im Backlog steht. Letztendlich wird sie uns untergehen lassen.
Aber muss das wirklich so sein?
Immer mehr fortschrittliche Unternehmen sind der Meinung, dass technische Schulden ein zentraler Bestandteil der Arbeit aller Softwareentwickler sein sollten und dass diese Teams durch ein proaktives Management der technischen Schulden nicht nur den Untergang vermeiden, sondern sogar die Konkurrenz überflügeln können.
Was sind technische Schulden?
Der Begriff der technischen Schuld wurde ursprünglich 1992 von dem Informatiker Ward Cunningham geprägt und beschreibt die Vorstellung, dass die Entwicklung kurzfristiger Lösungen für technische Systeme eine Reihe von Kompromissen mit sich bringt, die zu zukünftigen Verpflichtungen führen, die in Form von technischer Arbeit zurückgezahlt werden müssen.
Der Softwareentwickler Martin Fowler beschrieb dies im Jahr 2003 [weiterführende Artikel in Englisch]:
In dieser Metapher führt die schnelle und schmutzige Art, Dinge zu tun, zu einer technischen Schuld, die einer finanziellen Schuld ähnelt. Wie eine finanzielle Schuld führt auch die technische Schuld zu Zinszahlungen, die in Form von zusätzlichem Aufwand für die zukünftige Entwicklung anfallen.
-Martin Fowler
Laut dem Developer Coefficient-Bericht von Stripe aus dem Jahr 2018 verbringt der durchschnittliche Softwareentwickler mehr als 13 Stunden pro Woche damit, sich um technische Schulden zu kümmern. Da die Anwendungen immer komplexer werden, war die Verwaltung dieser Schulden noch nie so wichtig wie heute. „Jeder Code, den Sie als belastend eingestuft haben, ist technische Schuld“, so Alexandre Omeyer, CEO von Stepsize, gegenüber InfoWorld.
Technische Schulden können sehr unterschiedliche Formen annehmen. „Am unteren Ende kann es sich um einen kleinen Codebereich handeln, der überarbeitet werden muss, um Bibliotheken, die aktualisiert werden müssen, oder um Unit-Tests, die korrigiert werden müssen“, schrieb der InfoWorld-Kolumnist Isaac Sacolick letztes Jahr.
„Am oberen Ende der Skala gehören zu den technischen Schulden das Reengineering komplexer monolithischer Anwendungen, die Portierung veralteter Webservice-Protokolle, die Konsolidierung mehrerer Plattformen auf einen Standard, die Bereinigung von Datenschulden, die Modernisierung der Infrastruktur, die Einführung von Beobachtungspraktiken oder die Automatisierung eines Rückstands an manuellen Testfällen.
Die schlimmste Art von technischen Schulden ist eine ‚brennende Plattform‚, d. h. eine Plattform mit wiederkehrenden Ausfällen und Vorfällen, die das Geschäft beeinträchtigen.
Auch wenn die Arbeit an einer solchen Plattform weniger verlockend erscheint als die Bereitstellung neuer, attraktiver Funktionen, können die Entwickler nur dann längerfristig Schmerzen vermeiden, wenn sie die technischen Schulden proaktiv und kontinuierlich im Team angehen.
„Der Umgang mit technischen Schulden kommt oft zu kurz, da dies selten einen dringenden Geschäftsbedarf anspricht und insbesondere bei nicht dringenden Fällen der ROI unklar ist und daher als aufschiebbar angesehen wird“, schrieb Sacolick. „Das ist ein klassisches Problem für alles, was mit Wartung zu tun hat, egal ob es sich um Code oder Immobilien handelt.“
Der Blick in den Abgrund der technischen Schulden
Mik Kersten, Autor von Project to Product und Gründer von Tasktop, ist der Meinung, dass „technische Schulden eine Priorität sein müssen, die proaktiv angegangen werden muss. Leider ist das in vielen Fällen ein neues Konzept.“
Für viele Entwicklungsteams, vor allem in schnell wachsenden Unternehmen, stehen technische Schulden in einem Spannungsverhältnis zu der wichtigen Arbeit, neue Funktionen zu entwickeln. Für Charity Majors, CTO und Mitbegründer von Honeycomb, sind technische Schulden jedoch „ein Zeichen des Erfolgs, es bedeutet, dass man noch am Leben ist“.
Nur wenn man sich um die kleinen Dinge kümmert, kann man sicherstellen, dass sie nicht zu großen Plagegeistern heranwachsen“, so Majors gegenüber InfoWorld.
Auch wenn sich das leicht sagen lässt, muss ein kultureller Wandel in der gesamten Organisation stattfinden, um sicherzustellen, dass technische Schulden ernst genommen werden.
„Ein echtes Backlog zu haben, das 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 sie zwar Anreize haben, neue Dinge zu liefern, aber keine spezifischen leistungsbasierten Anreize haben, um gleichzeitig ihre technischen Schulden zu verwalten“, so die RedMonk-Analystin Rachel Stephens gegenüber InfoWorld.
Oder, wie Kersten von Tasktop sagte: „Wenn man nur Anreize für Funktionen schafft, begibt man sich in eine Todesspirale der technischen Schulden.“
Wie Sie Ihre technischen Schulden in den Griff bekommen
John Kodumal, CTO und Mitbegründer von LaunchDarkly, erklärte Anfang des Jahres gegenüber InfoWorld, dass „technische Schulden bei der Softwareentwicklung unvermeidlich sind“, dass es aber „viel gesünder ist, die Schulden im Laufe der Zeit proaktiv zu reduzieren, als andere Arbeiten zu stoppen und zu versuchen, sich aus einem Berg von Schulden herauszuwinden“.
Diese proaktive Herangehensweise an den Umgang mit technischen Schulden beinhaltet, dass man alles, was man als technische Schulden betrachten könnte, als ein weiteres Feature betrachtet, das in den normalen agilen Prozess einbezogen werden muss.
„Das Geheimnis, um Anwendungen aufrechtzuerhalten und den Legacy-Status zu vermeiden oder zumindest zu verzögern, liegt darin, wie Organisationen und Teams mit technischen Schulden umgehen“, schreibt Sacolick. Der Schlüssel ist, proaktiv zu sein, was bedeutet: „Festlegung von Richtlinien, Konventionen und Prozessen, um die Kosten für den Schuldenabbau im Laufe der Zeit zu amortisieren“.
Viele Teams werden versucht sein, eine bestimmte Menge an Kapazität für die Beseitigung technischer Schulden zu verwenden, z. B. 20 % eines jeden Sprints. Kersten von Tasktop rät jedoch zu einem dynamischeren Ansatz, der den Kontext der anstehenden Termine oder der Teamkapazität berücksichtigt.
„Sie sollten das Geschäftsergebnis und die Investition in technische Schulden messen und sicherstellen, dass sich diese ausgleichen“, so Kersten. „Machen Sie die technischen Schulden sichtbar, damit Sie immer wissen, wie viel Sie verwalten. Sobald sie sichtbar sind, sollten Sie einen Zielprozentsatz für die Umsetzung festlegen, der im Laufe der Zeit dynamisch sein muss.“
Für Ben Kus, CTO des Cloud-Speicherunternehmens Box, ist die Begleichung technischer Schulden etwas, das alle Entwicklungsteams in ihr Backlog aufnehmen müssen. „Natürlich wird das immer wieder verschoben, aber es sollte ein ständiges Gefühl dafür geben, dass man diese Dinge ständig in Angriff nimmt“, so Kus.
Kus empfiehlt jedoch nicht, bestimmten Ingenieuren die Aufgabe zuzuweisen, sich auf technische Schulden zu konzentrieren. „Nennen Sie es nicht so, denn das ist die Ursache für die Fluktuation“, sagte er. „Niemand will an technischen Schulden oder Refactoring oder ähnlichen Aufgaben arbeiten.“
Stattdessen versucht man bei Box, die Arbeit gleichmäßig auf die Entwicklungsteams aufzuteilen und Probleme während des Sprint-Prozesses, in Postmortems und auf Abruf aufzudecken. „Wir haben einen strengen Postmortem-Prozess und identifizieren Dinge, die wir beheben müssen, um zu verhindern, dass dieselben Probleme erneut auftreten“, so Kus. „Wir sind nicht so voreilig zu sagen: ‚Lasst alles stehen und liegen, um etwas zu beheben‘, aber wir machen deutlich, dass wir zur Rechenschaft gezogen werden, wenn ein Problem erneut auftritt. Das ist äußerst unangenehm, wenn etwas zum zweiten Mal passiert“.
Die Notwendigkeit des Bereitschaftsdienstes
Das Element der Bereitschaftsdienste wird immer wichtiger, da die Entwicklungsteams versuchen, die technischen Schulden, die sie ausbremsen, effektiv zu ermitteln und zu messen.
Engineering Manager wie Majors von Honeycomb befürworten es, Ingenieure regelmäßig von der Arbeit an neuen Funktionen abzuziehen, damit sie sich auf die Behebung, das Refactoring und die Automatisierung dieser Schulden konzentrieren können.
„Es ist wichtig, einen Ingenieur zu haben, der hauptsächlich für die kleinen Dinge verantwortlich ist. Und als Teil Ihrer Rufbereitschaft sollten Sie aktiv von der Produktarbeit abgehalten werden. Das bringt Flexibilität in ein System, das normalerweise sehr wenig Flexibilität hat“, so Majors.
Chris Evans ist der Gründer von Incident.io, einem Software-Startup, das sich auf die Reaktion auf Zwischenfälle spezialisiert hat. „Der ganze Sinn der Nachverfolgung von Dingen besteht darin, dieses stillschweigende Wissen auszumerzen“, so Evans gegenüber InfoWorld. „Sie werden für Dinge angepiepst, für die Sie nicht die besten Voraussetzungen mitbringen.“
Das mag zunächst beängstigend klingen, aber die Probleme werden behoben, und wenn man dann bei der Aufarbeitung von Vorfällen oder Postmortems hervorhebt, was schief gelaufen ist, wird die Bedeutung der Beseitigung der technischen Schulden deutlicher.
„Indem wir die operative Verantwortung für unsere Arbeit übernehmen, straffen wir die Rückkopplungsschleifen zwischen Versand und Betrieb. Das hilft uns, pragmatische technische Entscheidungen zu treffen und eine gesunde Spannung zwischen der Auslieferung von neuem Code und der Unterstützung und Verbesserung des Bestehenden zu schaffen“, schrieb Evans in einem Blogbeitrag im Dezember.
Zum Beispiel wurden die Ingenieure von Incident.io kürzlich durch Interaktionen mit einer ihrer Datenbanken gebremst. „Wir glauben, dass wir mit einer Woche Investition einen besseren Weg finden können, um mit der Datenbank zu interagieren, was sich auf die Art und Weise auswirken wird, wie wir in Zukunft jede Funktion entwickeln“, so Evans.
Und diese Erfolge sollten genauso gefeiert werden wie die Behebung eines größeren Problems oder die Einführung einer coolen neuen Funktion, sei es in Form von Charity Majors „Tiara of Technical Debt“ oder Mik Kerstens Feier der „Erledigung eines großen Brockens technischer Schulden wie der Gewinn eines neuen Kunden“.
Überdenken der technischen Schulden bei der Financial Times
Die Financial Times hat die letzten sechs Jahre damit verbracht, ihre Herangehensweise an technische Schulden neu zu gestalten. Im Jahr 2015 wurde die Website der britischen Zeitung von einer monolithischen App namens Falcon betrieben. Im Jahr 2016 wandelten die Entwickler des Unternehmens Falcon in eine Reihe von Mikroservices um, die nun in ihrer Gesamtheit Next heißen. Die 332 Code-Repositories, die daraus entstanden sind, werden von einer Reihe von dauerhaften Teams mit definierten Verantwortlichkeiten verwaltet, die von Anwendungen, Content Discovery und Anzeigen bis hin zu zentralen Plattformen reichen, die allein für 72 Repos verantwortlich sind.
„Nach etwa einem Jahr liefen die Dinge nicht mehr so gut“, sagte Anna Shipman, technische Direktorin für Kundenprodukte bei der Financial Times, auf der QCon-Konferenz im April in London.
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 Haufen technischer Schulden, zu verwaisten Codebasen, die niemand anfassen wollte, und zu einem schrumpfenden Pool von Ingenieuren, die bereit waren, außerhalb der Geschäftszeiten auf Abruf bereitzustehen.
Wie einer von Shipmans Kollegen ihr sagte: „Es fühlt sich nicht so an, als ob wir das System besitzen oder leiten würden. Wir schieben nur Bits rein.“
Um sich dagegen zu wehren, musste man sich bewusst um Ordnung bemühen, die Spukgestalten aus dem Weg räumen und die Komplexität akzeptieren, um sie besser verwalten zu können. Nur wenn die Teams die Verantwortung für ihre Technologiestapel hatten, konnte die Organisation damit beginnen, die technischen Schulden und den Spuk bewusster anzugehen.
„Es ist nicht etwas, das man neben der regulären Bereitstellung von Funktionen macht, sondern etwas, für das man Zeit einplanen muss“, so Shipman. „Das ist nicht einfach so zu machen. Es reicht nicht aus, ein bisschen aufzuräumen, und schon ist alles in Ordnung.“
Auch wenn es keine zentrale Vorgabe gibt, beispielsweise 20 % der gesamten Entwicklungszeit für die Beseitigung von Altlasten und die Verwaltung technischer Schulden zu verwenden, ist Shipman der Meinung, dass die Teams jetzt besser in der Lage sind, ein Gleichgewicht zwischen der Bereitstellung von Funktionen und technischen Schulden herzustellen.
Das Team überzeugen
Sobald Sie Ihr Verhältnis zu technischen Schulden in der gesamten Entwicklung neu bewertet haben und die Entwickler den Wert einer „Verlangsamung“ verstehen, um technische Schulden fortlaufend anzugehen, ist die Herausforderung damit noch nicht beendet. Sie müssen diesen Wert immer noch dem Senior Management vermitteln.
„Produkt- und Entwicklungsmanager verwenden ihre Zeit darauf, den Geschäftswert zu steigern, als ob mehr Schnickschnack der einzige Wert wäre, aber manchmal besteht der größte Wert darin, das Modell auf Vordermann zu bringen“, so Majors von Honeycomb.
Die Beseitigung der technischen Schulden ist vielleicht das erste, was bei der Verfolgung von Geschäftszielen zurückgestellt wird, aber es ist zwingend erforderlich, dass die technischen Manager diese Ansicht ändern.
„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“, schrieb David Van Couvering, Senior Principal Architect bei eBay, Anfang des Jahres in einem Blogpost.
Um dem Unternehmen die Risiken dieser brüchigen Systeme zu verdeutlichen, muss man oft ihre Sprache sprechen, indem man betont, wie die Beseitigung technischer Schulden es den Entwicklern ermöglicht, in Zukunft schneller voranzukommen, die Software sicherer zu machen und die Ingenieure bei Laune zu halten oder sie 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“, schrieb Van Couvering.
„Andere Ingenieure werden verstehen, wie wichtig diese Arbeit ist. Erzählen Sie eine Geschichte, in der Ihr Geschäftspartner der Held ist und Sie der vertrauenswürdige Führer. Sie müssen sich auf Geschäftskennzahlen wie Durchlaufzeit, Leistung und Qualität beziehen“, rät Shipman von der Financial Times.
Gehen Sie das Risiko nicht ein
Ein erfolgreiches Management der technischen Schulden 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 entstehen, wenn man die wachsenden Haufen technischer Schulden ignoriert, sind potenziell existenziell.
„Ihr Argument gegen technische Schulden wird gestärkt, wenn Sie sich darauf konzentrieren, Ihrem Geschäftspartner 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“, schrieb RedMonk-Analystin Rachel Stephens 2017.
Ja, attraktive neue Funktionen halten Kunden und Führungskräfte bei Laune, aber verschuldete Systeme können alles zum Stillstand bringen, und aus den Trümmern herauszuklettern, macht nicht gerade Spaß.
*Scott Carey ist leitender Redakteur für Nachrichten bei den fünf B2B-Marken von Foundry – Computerworld, CIO, CSO, Network World und InfoWorld.
Be the first to comment