Technische Schulden sind - trotz ihres Namens - kein rein technisches Problem

geschrieben von Jens Happe, Lesezeit 4 Minuten
In diesem Beitrag beschreiben wir sieben Prinzipien, die uns geholfen haben, besser mit technischen Schulden umzugehen.
Technische Schulden sind - trotz ihres Namens - kein rein technisches Problem

Technische Schulden gedeihen besonders gut in Umgebungen mit bestimmten Eigenschaften. Mangelnde Erfahrung in der Softwareentwicklung innerhalb eines Teams und fehlendes Bewusstsein für den Wert von gutem, leicht verständlichem Code sind beispielsweise starke Treiber. Zu hoher Druck schnell Features umzusetzen sowie zu viel Bürokratie, die Eigeninitiative unterbindet, sind weitere Faktoren, die auf ein Team einwirken und schnell zu technischen Schulden führen.

Kurz gesagt, Menschen, ihre Fähigkeiten und ihre Zusammenarbeit innerhalb und außerhalb eines Teams sind der ausschlaggebende Faktor für das Entstehen aber auch den Abbau von technischen Schulden. Also gilt es hier anzusetzen.

Im folgenden beschreiben wir sieben Prinzipien, die uns geholfen haben, besser mit technischen Schulden umzugehen.

  1. Das notwendige Bewusstsein schaffen. Technische Schulden sind allgegenwärtig [1]. Es ist wichtig sich dieser Tatsache bewusst zu sein. Obwohl viele Entwickler:innen einen guten Eindruck der technischen Schulden haben, ist die Wahrnehmung in der Dringlichkeit und der Schwere eines Problems dennoch bei jedem anders. Außerdem sind nicht alle technischen Schulden gleich. Es gibt technische Schulden, die sich stärker auf die tägliche Arbeit auswirken als andere.

    Damit der Abbau der technischen Schulden funktionieren kann, ist es essentiell, dass jeder im Team, von Entwicklern bis Produkt Management, die Probleme und deren Auswirkungen auf die tägliche Arbeit kennt. Nur so lässt sich gemeinsam entscheiden welche der technischen Schulden eine hohe Dringlichkeit haben und welche erst einmal warten können.

  2. Aufhören, Mist auf den Haufen zu werfen. Wenn technische Schulden ein großes Problem sind, besteht einer der ersten und effektivsten Schritte zur Verbesserung der Situation darin, möglichst wenig neue technische Schulden zu machen. Das ist leichter gesagt als getan. Gerade wenn sich bereits hohe technische Schulden angehäuft haben, zwingen diese einen oft bei weiteren Entwicklungen direkt neue Umwege zu gehen.

    Hier gilt meiner Ansicht nach das Prinzip von Fowler: Passe den Code durch Refactorings so an, dass sich die geplanten Änderungen leicht (oder zumindest leichter) umsetzen lassen. Aber selbst das kann schwierig bis unmöglich sein. Hier gilt es dann abzuwägen, ob das Feature trotzdem zeitnah umgesetzt werden soll oder erstmal warten muss, bis der entsprechende Teil umgebaut ist.

  3. Dem Team helfen, besseren Code zu schreiben. Der Aufbau (und Abbau) technischer Schulden hängt stark von der Erfahrung, dem Wissen und der Einstellung der Entwickler:innen ab. Code Reviews im Team und Pair Programming können helfen ein gemeinsames Verständnis von gutem Code aufzubauen. Auch wenn solche Maßnahmen zu Anfang die Entwicklungsgeschwindigkeit reduzieren, sind sie unserer Erfahrung nach essentiell um Wissen auszutauschen und eine gemeinsames Verständnis zu entwickeln. All das zahlt sich langfristig durch eine höhere Codequalität und höhere Entwicklungsgeschwindigkeit aus.
  4. Klare und nützliche technische Richtlinien aufstellen. Nützliche Richtlinien können ebenfalls helfen, langfristig die Codequalität zu verbessern. Dabei liegt die Betonung auf nützlich. Viele Richtlinien sind langweilige Dokumente von bestenfalls semi-interessanten Dingen. Nützliche Richtlinien beschreiben insbesondere unternehmensinterne Lösungen für immer wiederkehrende Probleme und Fragen, die jede Entwickler:in bei ihrer täglichen Arbeit antrifft. Ein einfaches Beispiel ist der gewünschte Aufbau / die gewünschte Umsetzung einer REST API. Idealerweise sind diese Richtlinien leicht auffindbar, so dass Lösungen zu einem konkreten Problem bzw. einer Frage schnell gefunden werden können, z.B. über ein firmeninternes StackOverflow.
  5. Fokus auf die schmerzhaftesten Punkte. Nicht alle technischen Schulden sind gleich. Einige haben einen starken Einfluss auf die tägliche Arbeit, andere wirken sich kaum aus. Daher ist es wichtig, sich von Anfang an auf die Beseitigung der größten Schmerzpunkte zu konzentrieren. Mit einer schlichten "Aufwand/Nutzen"-Matrix, lässt sich relativ einfach feststellen, welche technischen Schulden besonders hohe Schmerzen verursachen und recht einfach zu beseitigen sind. Es bietet sich an mit den Refactorings zu beginnen, die einen hohen Nutzen bei relativ geringem Aufwand bieten. Jedes Refactoring, jede Maßnahme die man ergreift, um schlechten Code zu entfernen, bringt dann eine unmittelbare Verbesserung. Wenn man das hinbekommt, hat man auch eine gute Chance insgesamt schnell Linderung zu schaffen.
  6. Umbauten zu Beginn einfach halten. Die Versuchung ist groß, gleich die größten Punkte anzugehen und dabei alles umzuwerfen. Das ist meist keine gute Idee. Gerade zu Anfang ist es wichtig, erst einmal ein Gefühl für das Vorgehen und den Aufwand zu bekommen. Daher ist es unserer Erfahrung nach gut, mit etwas relativ Einfachem, aber Nützlichen zu starten und das zu verbessern. Dabei wird das Team bereits jede Menge lernen. Von da aus kann man sich weiterentwickeln und auch größere Probleme angehen. Erste Ergebnisse geben Sicherheit und beschleunigen den Prozess mit der Zeit.
  7. Grenzen akzeptieren. Alle Probleme in einem System zu lösen ist in den meisten Fällen unmöglich und vor allen Dingen gar nicht sinnvoll. Hier gilt das Pareto-Prinzip: 20% der technischen Schulden verursachen 80% des Schmerzes bei der täglichen Arbeit. Es ist in den meisten Fällen völlig ausreichend, die zentralen 20% der technischen Schulden anzugehen. Zusätzlich ist es hilfreich, klare Grenzen zu setzen und zu akzeptieren, dass bestimmte technische Schulden bis auf weiteres nicht abgebaut werden. Das ist insbesondere in der Kommunikation mit und unter den Entwickler:innen wichtig, um eine klare Erwartungshaltung aufzubauen.

Der Abbau technischer Schulden ist keine einmalige Aktion, sondern ein Prozess, der die Softwareentwicklung dauerhaft begleitet. Es liegt leider in der Natur von technischen Schulden, dass kontinuierlich neue hinzukommen [1] und einige nur sehr langsam und langfristig abgebaut werden können. Als Konsequenz daraus gilt:

Der Abbau technischer Schulden ist wie Rudern gegen den Strom; wer aufhört, treibt ab und geht irgendwann unter.

Nichtsdestotrotz ist es gerade bei einem Thema wie technischen Schulden wichtig, die (kleinen) Erfolge zu feiern, die Verbesserungen bewusst wahrzunehmen und die Reise zu genießen 😉 Nur so kann man das notwendige Momentum aufbauen und auch dauerhaft halten.