Was sind technische Schulden, und warum kosten sie Sie still und leise Geld?

Eine Funktionsanfrage, die früher zwei Tage dauerte, dauert jetzt zwei Wochen, und niemand kann genau sagen, warum. Die ehrliche Antwort lautet meist irgendeine Version von "da drin ist es kompliziert." Diese Komplikation hat einen Namen: technische Schulden. Das ist keine Entwicklerbeschwerde. Es ist ein echter Kostenpunkt in Ihren Büchern, Sie haben ihn nur noch nie als eigene Zeile gesehen.

Technische Schulden entstehen, wenn Software mit Abkürzungen gebaut wird, unter Zeitdruck, mit dem Plan, das später aufzuräumen. Die Analogie ist ein Kredit: Sie leihen sich jetzt Zeit, indem Sie einen sauberen Fix, einen Test, ein bisschen Aufräumen überspringen, und zahlen es später mit Zinsen zurück, in Form von langsamerer Arbeit und mehr Fehlern. Den Kredit aufzunehmen ist nicht immer ein Fehler. Eine funktionierende Version zwei Wochen früher zu liefern, um endlich zahlende Kunden zu bekommen, ist oft die richtige Entscheidung. Das Problem ist, dass ihn fast niemand zurückzahlt, weil es immer schon den nächsten Termin gibt.

Es zeigt sich auf ganz gewöhnliche Weise. Dieselbe Logik, in drei verschiedene Stellen kopiert, weil niemand Zeit hatte, sie einmal sauber zu bauen und wiederzuverwenden. Eine Bibliothek, die drei Hauptversionen hinterherhinkt, weil ein Update etwas kaputt machen könnte und niemand derjenige sein will, der das herausfindet. Ein Workaround für einen Fehler, der eigentlich provisorisch sein sollte, vor zwei Jahren geschrieben, von dem mittlerweile die halbe Codebasis still und heimlich abhängt. Für sich genommen wirkt nichts davon dramatisch. Es summiert sich.

Die Kosten zeigen sich in allem, was danach kommt. Änderungen, die eigentlich einfach sein sollten, erfordern erst, dass jemand ein Gewirr aus Code versteht, an das sich niemand mehr richtig erinnert, es geschrieben zu haben. Fehler werden schwerer aufzuspüren, weil ein Fix an einer Stelle Nebenwirkungen drei Dateien weiter hat, die niemand vorhergesehen hat. Schätzungen bedeuten irgendwann nichts mehr, weil aus "wie lange dauert das" still und heimlich "wie lange dauert das, plus wie lange es dauert, den Teil zu entwirren, den wir gerade anfassen" wird. Und jede veraltete Abhängigkeit, die da herumliegt, ist auch eine Sicherheitslücke, um die sich niemand aktiv kümmert.

1. Das ist nicht dasselbe wie schlechter Code. Ein gut gebautes System, das bewusst Schulden aufnimmt, um einen echten Termin zu halten, mit dem Plan, später darauf zurückzukommen, ist eine normale und oft kluge unternehmerische Entscheidung. Die Schulden, die wirklich wehtun, sind die, die niemand bewusst aufgenommen hat, sie haben sich einfach angesammelt, weil niemand hingeschaut hat.

2. Sie wachsen mit Zinsen. Eine Abkürzung, die Sie heute eine zusätzliche Stunde kostet, kostet mehr, je länger sie liegen bleibt, weil mehr Code darauf aufbaut, und sie später zu entwirren bedeutet, auch alles zu entwirren, was inzwischen davon abhängt. Derselbe Fix ist jetzt immer günstiger als in einem Jahr.

3. Es gibt Anzeichen. Wenn Schätzungen für einfach klingende Änderungen immer wieder hoch ausfallen, wenn es Dateien oder Funktionen gibt, die Ihr Team sichtlich meidet, wenn aus "schneller Fix"-Anfragen regelmäßig mehrtägige Untersuchungen werden, tragen Sie mehr Schulden, als Sie denken, egal ob das schon mal jemand so genannt hat.

4. Sie abzubauen heißt nicht, alles stehen und liegen zu lassen, um das System neu zu schreiben. Unternehmen, die das gut hinbekommen, behandeln Aufräumen als normalen Teil der Arbeit, nicht als eigenes Projekt: Wenn Sie ohnehin gerade eine unordentliche Stelle im Code anfassen, um ein Feature hinzuzufügen, räumen Sie die Unordnung gleich mit auf, statt noch eine Abkürzung obendrauf zu legen. Wenig, aber regelmäßig, schlägt eine große Neuschreibung, die immer wieder nach hinten rutscht, sobald etwas Dringendes dazwischenkommt.

5. Eine komplette Neuschreibung ist selten die Antwort, und seien Sie skeptisch gegenüber allen, die sie als ersten Schritt vorschlagen. Neuschreibungen sind teuer, langsam, werden regelmäßig unterschätzt, und sie setzen das ganze System auf einmal aufs Spiel, statt es schrittweise zu verbessern. Gezieltes Aufräumen der Stellen, die wirklich Probleme verursachen, schlägt fast immer einen Neuanfang.

Wenn Ihr Team bei einer einfach klingenden Anfrage immer wieder sagt, "so einfach ist das nicht," nehmen Sie das ernst, nicht als Beschwerde über den Code, sondern als Information darüber, wo Ihr Geld tatsächlich hingeht. Wir schauen uns an, was wirklich bremst, bevor wir irgendetwas empfehlen, Aufräumen, eine teilweise Neuschreibung, oder einen funktionierenden Teil des Systems einfach in Ruhe zu lassen, und Sie bekommen eine klare Antwort von der Person, die sich den Code tatsächlich angesehen hat, keinen Verkaufspitch für ein größeres Projekt, als Sie brauchen.

Technische Schulden und die Entscheidung zwischen Standard- und individueller Software sind zwei Seiten derselben Medaille: Bei beidem geht es darum, wie viel Sie später für das bezahlen wollen, was jetzt bequem ist. Standard- oder individuelle Software? So entscheiden Sie wirklich, falls Sie vor genau dieser Wahl stehen. Und wenn das Symptom, das Sie eigentlich sehen, eine langsame Website statt langsamer Entwicklung ist, hier ist eine echte Diagnose-Checkliste. So oder so, genau dafür ist unser Support & Maintenance-Angebot da.