Möglichkeiten für den richtigen Umgang mit technischen Schulden

In diesem Blogbeitrag findest du eine Zusammenfassung eines Kurzvortrags von mir. Ich hatte damals das Thema Technische Schulden gewählt, da mir Qualität sehr wichtig ist und dieses Thema meiner Meinung nach ein wesentlicher Beitrag für ein erfolgreiches Produkt darstellt. Daher habe ich recherchiert, wie der richtige Umgang mit technischen Schulden aussehen könnte.

Was sind technische Schulden?

Die technische Schuld ist eine Metapher, die bereits 1992 von Ward Cunningham geprägt wurde und stellt eine Aussage über einen zusätzlichen Aufwand dar, den man für Änderungen und Erweiterungen an einer schlecht geschriebener Software im Vergleich zu einer gut geschriebener Software eingeplant müsste. Jede Technische Schuld macht gemäß Tom Popendieck den Code schwerer zu ändern und hat somit direkten Einfluss auf die Wartbarkeit.

Im Alltag hat sich schnell ein solcher Fehler eingeschlichen, indem eine Codestelle schnell kopiert wird oder die Dokumentation des Codes vernachlässigt wird, da man es erst später machen will. Auch eine in die Jahre gekommene Architektur oder ein unzureichender Test führt zu einer technischen Schuld.

Was sind die langfristigen Auswirkungen?

Folgende Auswirkungen entstehen in den verschiedenen Bereichen, wenn technischen Schulden ignoriert oder immer nur Symptome bekämpft werden:

• Schlecht motiviertes Team mit niedriger Performance.
• Je nach technischer Schuld können auch weniger innovative Neuentwicklungen oder Erweiterung die Folge sein.
• Time to market verringert sich und Entwicklungskosten steigen, wenn Erweiterungen nur mit Umwegen auf Basis von schlechten Code entwickelt werden kann.
• Negative Rückmeldungen vom Kunden, beispielsweise hinsichtlich Performance, sind kontinuierlich vorhanden. Somit verschlechtert sich auf Dauer die Kundenzufriedenheit und der Ruf des Unternehmens leidet.
• Die Anzahl ist exponentiell steigend. Somit befindet man sich irgendwann in einer Abwärtsspirale.

Was sind die Ursachen von technischen Schulden?

Martin Fowler stellt in seinem Technical Debt Quadranten eine Kategorisierung zur Verfügung, in dem ersichtlich wird, dass technischen Schulden entweder Absichtlich (Deliberate) oder Unbeabsichtigt (Inadvertent) entstehen. Zusätzlich unterscheidet er, ob dies Leichtsinnig (Reckless) oder Bewusst (Prudent) geschehen ist.

Absichtlich und Leichtsinnig

Dies beruht meistens aufgrund einer Managemententscheidung und entspricht nicht dem agilen Qualitätsverständnis. Einen Umbau zur Sicherstellung der Qualität von solchen “Quick & Dirty” Lösungen werden auch nicht in Zukunft eingeplant, sondern werden ggf. erst wieder relevant, wenn sich der Kunde beschwert.

Absichtlich und Bewusst

Die Entscheidung wird bewusst getroffen, um als Business Driver auf dem Markt agieren zu können. Die entsprechenden Risiken sind bekannt und es ist eingeplant, die technischen Schulden hier wieder zu reduzieren.

Erfolgt dies allerdings nicht, ist die technische Schuld irgendwann im ersten Quadranten angesiedelt.

Unbeabsichtigt und Leichtsinnig

Aufgrund von fehlendem Wissen können in diesem Fall unbewusst technischen Schulden entstehen. Durch Code Review, Coding Guidelines oder der Definition of Done in Scrum und entsprechenden Schulungen kann hier vorgebeugt werden.

Unbeabsichtigt und Bewusst

Zum Zeitpunkt der Entwicklung entsprach die Umsetzung dem damaligen Wissens- und Technikstand. Da eine Weiterentwicklung sowohl in der Technik als auch Wissen vorhanden ist, würde unter Umständen die Umsetzung nun anders aussehen. Durch ein nachträgliches Refactoring kann hier eine Verbesserung des Codes erzielt werden.

Wie soll man mit technischen Schulden nun umgehen?

1) Strategische Entscheidungen

Auf Basis einer Produkt-Portfolio Matrix, in der der Erfüllungsgrad der bereits umgesetzten und die zukünftigen Anforderungen gegenübergestellt wird, kann eine Entscheidung getroffen werden, wie mit der technischen Schuld umgegangen werden soll.

• Problem Childs: In den gerade in der Entwicklung befindlichen Produkte sollten die technische Schulden prinzipiell vermieden, damit Innovationen überhaupt möglich werden.
• Rising Stars: Da dies die zukünftigen Cash Cows werden könnten, müssen die technischen Schulden alle ohne Kompromisse entfernt werden.
• Cash Cow: Mit diesen Produkten wird das Geld verdient, so dass hier die Wartbarkeit eine große Rolle spielt. Die technischen Schulden müssen somit immer wieder neu betrachtet und kontinuierlich reduziert werden.
• Poor Dogs: Hier sind die Produkte angesiedelt, die kein Geld (mehr) bringen und nichts mehr investiert werden sollte. Hier können die technischen Schulden einfach ignoriert werden.

2) Visualisierung

Es stehen zahlreiche Tools zur Verfügung, mit dessen Hilfe eine statische Code Analyse durchgeführt werden kann. Es können auf Basis verschiedener Qualitätsmetriken wie potentielle Bugs, nicht eingehaltene Coding Standards, Doppelter Code, Fehlende Dokumentation, Unit test und Testabdeckung eine ungefähre Abschätzung berechnet werden. Somit können technische Schulden kontinuierlich überwacht werden, so dass entsprechende Maßnahmen abgeleitet werden können.

Beispiele: ReSharper, SonarQube, Checkstyle

Zusätzlich sollten technische Schulden ebenfalls in einem globalen Backlog in einem Issue Tracker System wie JIRA mit einem eigenen Issue Type gepflegt werden. Zusätzlich ist es sinnvoll eine technische Schuld mit einem “Pain factor” zu versehen, mit Hilfe diesem eine Aussage getroffen werden kann, wie schmerzhalft es ist, wenn die technische Schuld nicht behoben wird.

3) Scrum

Scrum bietet einen guten Rahmen, dass das Scrum Team mit technischen Schulden umgehen kann:

• Scrum Master: Der Scrum Master ist dafür zuständig, dass das Management die technischen Schulden als solche wahrnimmt. Für das Team stellt er die Möglichkeiten sicher, dass technische Schulden in erster Linie vermieden, aber auch reduziert werden können.

• Product Owner: Der Product Owner übernimmt die Verantwortung für die Pflege der bestehenden technischen Schulden im globalen Backlog mit Pain factor. Auf Basis des Pain factors und je nach Strategie erfolgt die Priorisierung und es werden vom PO die entsprechenden Stories in der Sprintplanung vorgesehen.
• Development Team: Dem Team stehen verschiedene Methoden zur Verfügung, damit von vorneherein technische Schulden vermieden werden können:
  • Definition of Done: Festlegung, keine neuen technischen Schulden aufzubauen, Messbar mit Tools für die statische Code Analyse. 
  • Pair programming und Code Review: Auf Basis des Vier-Augen Prinzip und Wissensverteilung kann technische Schulden vermieden werden
  • Coding Guidelines
  • Test Driven Development

Fazit

Es ist somit sehr gut möglich, vor allem mit einer agilen Vorgehensweise, technische Schulden in den Griff zu bekommen. Es stehen unterschiedliche Methoden zur Verfügung, so dass technische Schulden beherrschbar werden. Qualität bleibt einfach der Stellhebel dafür.

Link-Tip: Kennst du schon meine Agile Lernreise zum professionellen Software Entwickler?