Technische Schulden (II)

Bild: Pixabay / Raten-Kauf - Lizenz

Wir müssen noch einmal über das Thema der technischen Schulden sprechen, genauer gesagt über eines der grössten damit verbundenen Probleme: die Unklarheit darüber was mit diesem Begriff eigentlich gemeint ist. Wie bereits gesagt ist nicht jeder Fehler oder jeder Qualitätsmangel im Code automatisch eine technische Schuld, das ist nur dann der Fall wenn diese Missstände bewust in Kauf genommen wurden um ein anderes Ziel zu erreichen. Aber auch das ist noch nicht alles.

Tatsächlich kann es auch technische Schulden geben die nicht bewusst "aufgenommen" wurden sondern mehr oder weniger versehentlich entstanden sind oder von jemand anderem (einem anderen Team, einem Zulieferer, einem aufgekauften Wettbewerber, etc) übernommen wurden. Das Entscheidende ist in diesen Fällen nicht mehr der Entstehungskontext sondern etwas Anderes - der Beschluss die Behebung in die Zukunft zu verschieben.

Um das besser zu verstehen ein kurzer Einschub: eigenlich ist es Best Practice Good Practice Fehler in der Software sofort zu beheben sobald sie entdeckt werden (🡪 Zero Bug Policy). Unterbleibt das besteht ein erhebliches Risiko, dass es zu einem "Jenga-Effekt" kommt: weitere, neue Funktionen bauen (bewusst oder unbewusst) auf den bestehenden, fehlerhaften auf, und wenn diese repariert und dadurch verändert werden stürzt das ganze Konstrukt in sich zusammen.

Es kann  aber Gründe dafür geben diese Reparaturen nicht sofort vorzunehmen, vor allem dann wenn ein wichtiger Liefertermin anliegt und für die entdeckten Fehler ein kurzfristiger Workaround möglich, eine sofortige Behebung dagegen relativ aufwändig wäre. Um den Termin einhalten zu können kann es in solchen Situationen Sinn machen die mit einer späteren Reparatur verbundenen Mehraufwände zu akzeptieren - und genau das ist nichts anderes als das Aufnehmen technischer Schulden.

Ist das ein realistisches Szenario? Es kommt darauf an, wie so oft. Bei stabilen Teams die langfristig an einem Produkt arbeiten ist diese Art der technischen Schuld eher ein Ausnahmefall, in Organisationen in denen Software in einer Abfolge von Projekten mit wechselnder Personalbesetzung entwickelt wird ist es eher die Regel, genauso in Systemlandschaften mit vielen Legacy-Anwendungen. Und seien wir ehrlich, die beiden letzten Typen sind in Konzernen der Normalfall.

Das Ergebnis dieser "Normalität" ist eine Art von Generationenvertrag - die aktuelle Entwicklergeneration hält ihre Systeme durch die Aufnahme technischer Schulden irgendwie am Laufen und kann sie so (mehr oder weniger) funktionierend an ihre Nachfolger übergeben, die dann vor der Wahl stehen sie in Form von Reparatur- und Aufräumarbeiten abzubezahlen oder noch mehr aufzunehmen und das Problem an die übernächste Generation weiterzugeben.

Und nochmal, auch dieses Weitergeben von immer schlimmer werdenden technischen Schulden über mehrere Generationen hinweg ist leider nicht unrealistisch, verbunden mit Wassermelonen-Projekten und Arschkarten-Lücken tritt es immer wieder auf. Um aber auch die andere Option zu nennen: ich habe es auch erleben dürfen, dass "geerbte" technische Schulden nach und nach abgebaut wurden. Das war anstrengend und fühlte sich ungerecht an, dafür wurde ab diesem Zeitpunkt alles wieder leichter.