Technical Debt verstehen: So wichtig ist es für Entwickler

Manchmal müssen Teile der Software schneller veröffentlicht werden, als geplant. Die technische Ebene kann dabei vernachlässigt werden, da die Zielerreichung höhere Priorität hat. Genau da setzt Technical Debt an. Was das bedeutet, wie es entsteht und warum es nicht nur als reine Schuld definiert werden kann, erklären wir dir in diesem Beitrag mal genauer.

Was heißt Technical Debt?

Unter dem Begriff Technical Debt (deutsch: Technische Schulden) versteht sich eine Metapher für eine Kompromisslösung in der Softwareentwicklung. Wenn Kosten oder Zeit eingespart werden um ein Produkt oder neues Feature schneller an den Markt zu bringen beschreibt das einen Trade-Off, der umgangssprachlich auch als Techinical Debt beschrieben wird.

Bespiele für Technical Debt

Technical Debt kann sich in verschiedenen Weisen in den Entwicklungsprozess schleichen. Egal, ob es um den eigentlichen Coding und Design Aspekte geht oder die Architektur sowie Testing-Vorgänge.

Bekannte Technical Debt Beispiele in der Praxis von Softwareentwicklern sind:

• Schlechte Namensgebung und inkonsistenter Code-Stil

• Einfügen von Copy-Paste Code

• KI-generierter Code ohne korrekte Review der Tests von Menschen

• Umsetzung von manuelle Deployments

• Nutzung von veralteten Servern

• Fehlende oder veraltete Dokumentation

• Fehlendes Monitoring und Logging

• God Classes und überlange Methoden

• Hardcoded Werte

Warum entsteht Technical Debt?

Wenn technische Schulden eingegangen werden ist es häufig wichtiger ein Ziel zu erreichen, statt den bestmöglichen Code für die Lösung zu schreiben. Der Begriff “Schulden” bezieht sich also darauf zwar schneller Handeln zu können, im Nachhinein aber mit Problemen konfrontiert zu werden, die bei optimaler Umsetzung und hoher Code-Qualität sehr wahrscheinlich nicht aufgekommen wären.

Technische Schulden als Darlehen

Technische Schulden werden häufig als Fehler im Prozess angesehen, den es zu korrigieren gilt. Das mag in mancher Hinsicht stimmen, jedoch kann es auch gleichzeitig als eine Art Darlehen gesehen werden. Denn die Frage ist nicht, ob ein Team Technische Schulden aufweist, sondern ob sie sich diese Entscheidung aktiv ausgesucht haben.

Technische Schulden können in einigen Situationen sogar sinnvoll sein. Beispielsweise dann, wenn sich die Gegebenheiten oder Ansprüche an ein Tool oder Feature in der Zukunft sowieso noch weiter entwickeln werden.

Auch kann es sehr gut sein, dass es zu höheren Kosten kommt, wenn das Tool überhaupt nicht an den Markt gebracht wird. Daher kann es Sinn machen die Technischen Schulden in Kauf zu nehmen, ein Produkt oder Tool in unfertiger Form zu veröffentlichen und damit auf größere Einbußen zu verzichten.

Natürlich sollte man Technische Schulden in besonders relevanten Bereichen einer Applikation weiterhin stark kritisch betrachten und nicht einfach so hinnehmen. Gerade für Punkte wie die Authentifizierung oder die Zuweisung von Berechtigungen trifft das zu. Hier dürfen sich keine halb-fertigen Versionen einschleichen, die letztendlich schwerwiegende Folgen haben können.

Technische Schulden: Der richtige Umgang ist entscheidend

Es bleibt sowohl für Teams als auch Entscheider wichtig zu verstehen, wo Abkürzungen genommen wurden und wie diese sich auf den aktuellen Prozess ausgewirkt haben, sowie welche Probleme dadruch eventuell in Zukunft auftreten könnten. Das Team muss regelmäßig prüfen, ob der Trade-Off weiterhin sinnvoll ist oder nicht.