Zurück zu Insights
BADA Solutions
Strategie 10 Min Lesezeit

Die wahren Kosten technischer Schulden

Jede Zeile Code, die heute eine Abkürzung nimmt, ist ein Kredit auf Ihre Zukunft. So berechnen Sie den Zinssatz.

Stakeholder denken oft an Code wie an einen Vermögenswert, wie ein Gebäude. Wenn es gebaut ist, ist es fertig. Aber Code ist eher wie ein Garten. Wenn Sie aufhören zu jäten, übernehmen das Unkraut, und schließlich finden Sie nicht einmal mehr das Gemüse.

Die Finanzanalogie

Ward Cunningham prägte die Metapher „Technische Schuld“, um Refactoring Finanz-Stakeholdern zu erklären. Es geht so:

  • Kapital: Der schnelle und schmutzige Code, den Sie geliefert haben, um eine Deadline einzuhalten.
  • Zinsen: Die zusätzliche Zeit, die Sie jedes Mal verbringe, um um diesen Code herumzuarbeiten, wenn Sie eine neue Funktion hinzufügen.

Wenn Sie das Kapital nicht zurückzahlen (Refactoring), verbringen Sie schließlich 100% Ihrer Zeit damit, Zinsen zu zahlen (Fehlerbehebung durch schlechten Code) und haben null Kapazität für neue Funktionen (Bankrott).


Verzögerungskosten (Zinseszins)

xychart-beta title „Kosten von Änderungen über die Zeit“ x-axis [Jahr 1, Jahr 2, Jahr 3, Jahr 4, Jahr 5] y-axis „Dev Stunden pro Feature“ 0 –> 100 line [10, 15, 35, 60, 95] bar [10, 12, 12, 12, 12] %% Legende: Balken = Ideal, Linie = Mit Schulden

Balken: Ideale Geschwindigkeit | Linie: Realität mit Schulden

Die Gefahr des Zinseszinses

Technische Schuld verzinst sich. Wenn Sie ein hackiges Modul haben, schreiben Sie einen hackigen Workaround in einem anderen Modul, um damit zu sprechen. Jetzt haben Sie zwei Hacks. Dann kommt ein neuer Entwickler, sieht die Hacks und denkt „so machen wir das hier“.

Innerhalb eines Jahres fällt Ihre „Geschwindigkeit“ von 10 Features/Monat auf 1 Feature/Monat.

Der „Es funktioniert“ Irrtum

Nur weil Code „funktioniert“ (QA besteht), heißt das nicht, dass er Wert hat. Wenn er nicht wartbar ist, hat er negativen Wert.

Unsere Rückzahlungsstrategie

Bei BADA Solutions setzen wir bei unseren Unternehmenskunden eine strikte 80/20-Regel durch:

  • 80% Neue Features: Geschäftswert liefern.
  • 20% Refactoring: Schulden in den Bereichen zurückzahlen, die wir anfassen.

Das ist die „Pfadfinder-Regel“: Hinterlasse den Campingplatz sauberer, als du ihn vorgefunden hast. Wenn wir ein Modul anfassen, um einen Button hinzuzufügen, benennen wir auch die verwirrenden Variablen um und fügen den fehlenden Unit-Test hinzu.

Bereit zu skalieren?

Wir sind spezialisiert auf Enterprise Software Engineering. Lassen Sie uns über Ihre Architektur sprechen.

Beratung Vereinbaren