Der Markt wollte mehr. Das System nicht.
Das Produkt lief gut. Besser als gut – der Markt hatte es angenommen und schrie nach mehr. Neue Integrationen, neue Payment-Provider, neue Features die Wachstum bedeuteten. Das Timing war perfekt. Die Infrastruktur nicht.
Die Payment-API auf der ich arbeitete lief unter PHP 5.6. Nicht weil niemand es besser gewusst hätte. Sondern weil der Feature-Druck jahrelang höher war als die Zeit die ein Upgrade gebraucht hätte. Jedes Quartal gab es wichtigere Dinge. Jedes Quartal wurde das Upgrade verschoben.
Bis die SDKs der neuen Payment-Provider PHP 7.2 voraussetzten.
Was folgte waren Wochen in denen keine einzige neue Funktion geliefert werden konnte. Kein neuer Payment-Provider. Kein neues Feature. Nur das Upgrade das schon lange überfällig war – und das jetzt unter maximalem Druck erledigt werden musste weil es keine andere Wahl mehr gab.
Technische Schulden waren zu diesem Zeitpunkt kein Entwickler-Problem mehr. Sie waren ein Geschäftsproblem.
Was technische Schulden wirklich sind
Technische Schulden sind aufgeschobene Entscheidungen die mit Zinsen zurückgezahlt werden. Jede Abkürzung die ein Team heute nimmt macht eine Änderung morgen teurer. Das ist keine Metapher – es ist Mechanik.
In einem System das jahrelang unter Feature-Druck stand ohne Zeit für Aufräumarbeiten akkumulieren sich diese Entscheidungen. Nicht dramatisch. Nicht sichtbar. Sondern still – bis der Moment kommt wo eine eigentlich triviale Änderung Wochen dauert weil niemand mehr versteht wie die Teile zusammenhängen.
Genau das ist in meinem Projekt passiert. Nicht weil schlechte Entwickler am Werk waren. Sondern weil gute Entwickler unter Druck immer das Richtige für heute tun – und das Richtige für morgen verschieben bis morgen keine Option mehr ist.
Warum niemand zuhört
Ich habe in dem Projekt früh darauf hingewiesen. Nicht einmal – immer wieder. Das PHP-Upgrade war überfällig. Die Schulden wuchsen. Der Moment würde kommen wo es nicht mehr anders geht.
Die Antwort war immer dieselbe. Wir wissen es. Aber jetzt haben wir dieses Feature. Und danach jenes. Und dann die nächste Deadline. Irgendwann machen wir das.
Das ist keine Böswilligkeit. Es ist eine rationale Reaktion auf kurzfristigen Druck. Technische Schulden sind in der Zukunft. Das nächste Feature ist in zwei Wochen. Und in jedem Meeting in dem um Prioritäten gerungen wird verlieren abstrakte zukünftige Risiken gegen konkrete aktuelle Anforderungen.
Das Problem ist dass technische Schulden nicht warten bis sie eingeplant werden. Sie wachsen still – und werden sichtbar genau dann wenn kein Platz dafür ist.
Wie ich es CTOs erkläre
Der Fehler den viele Entwickler machen ist technische Schulden als technisches Problem zu kommunizieren. Refactoring, Code-Qualität, Architektur – das sind Begriffe die im C-Level keine Dringlichkeit erzeugen.
Was Dringlichkeit erzeugt ist Geschäftswirkung.
Die Frage die ich stelle ist nicht: Wann können wir das Upgrade machen? Die Frage ist: Was kostet uns dieses Upgrade wenn wir es jetzt machen – und was kostet es uns wenn wir es in einem Jahr unter Druck machen weil wir keine andere Wahl mehr haben?
In meinem Fall war die Antwort eindeutig. Das Upgrade unter Druck kostete Wochen ohne Feature-Lieferung in einem Moment wo der Markt auf uns wartete. Hätten wir es sechs Monate früher geplant hätte es einen Sprint gekostet ohne externe Deadline und ohne Wachstumsbremse.
Der zweite Hebel ist Sichtbarkeit. Technische Schulden müssen messbar sein um ernst genommen zu werden. Wie lange dauert ein durchschnittliches Feature heute verglichen mit vor zwei Jahren? Wie viele Bugs entstehen durch Code der niemand mehr versteht? Wie viel Entwicklerzeit fließt in Fixes statt in Features? Diese Zahlen erzählen eine Geschichte die ohne Zahlen niemand hört.
Der dritte Hebel ist Timing. Technische Schulden zu einem Problem zu machen das niemanden interessiert funktioniert nicht. Sie als strategische Investition zu positionieren schon. Der Unterschied zwischen "wir müssen refactoren" und "wir müssen jetzt investieren damit wir in sechs Monaten schneller liefern können" ist derselbe Sachverhalt – aber einer landet im C-Level und einer nicht.
Was wirklich hilft
Nach der Erfahrung mit der Payment-API habe ich verändert wie ich über technische Schulden spreche. Nicht mehr über Code – sondern über Wachstumsfähigkeit.
Die konkreteste Frage die ich stelle ist: Wie lange hat ein durchschnittliches Feature vor zwei Jahren gedauert – und wie lange dauert es heute? Wenn die Antwort "deutlich länger" ist ohne dass das Team größer geworden ist oder die Features komplexer wurden liegt der Grund fast immer in akkumulierten technischen Schulden. Diese Zahl ist keine technische Metrik. Sie ist ein Geschäftsindikator.
Dasselbe gilt für den Anteil der Entwicklerzeit der in Bugfixes und ungeplantem Aufwand verschwindet statt in Features zu fließen. Wenn ein Team 40 Prozent seiner Zeit damit verbringt bestehenden Code zu stabilisieren bedeutet das dass 40 Prozent des Entwicklungsbudgets nicht in Wachstum investiert werden. Das ist eine Zahl die im C-Level ankommt.
Der dritte Hebel ist Timing. Technische Schulden als strategische Investition zu positionieren funktioniert besser als sie als Problem zu kommunizieren. Der Unterschied zwischen "wir müssen refactoren" und "wir investieren jetzt einen Sprint damit wir in sechs Monaten doppelt so schnell liefern können" ist derselbe Sachverhalt – aber einer landet im C-Level und einer nicht.
Der Moment der Klarheit
In dem Projekt mit der Payment-API kam der Moment der Klarheit nicht durch eine überzeugende Präsentation oder eine gut formulierte E-Mail. Er kam weil es keine andere Wahl mehr gab.
Das ist der teuerste Weg technische Schulden zu verstehen. Er kostet Zeit, Wachstum und in manchen Fällen Marktanteile die in der Zwischenzeit an Wettbewerber gegangen sind.
Die Alternative ist unbequem aber billiger: technische Schulden sichtbar machen bevor sie eskalieren, in Geschäftssprache übersetzen statt in technische Begriffe, und konsequent als strategisches Risiko kommunizieren – nicht als Entwicklerpräferenz.
Ich habe in diesem Projekt früh gewarnt. Ich wurde gehört aber nicht priorisiert. Das ist ein Muster das ich seitdem in fast jedem gewachsenen System wiederfinde.
Technische Schulden warten nicht. Sie wachsen. Und sie werden sichtbar genau dann wenn niemand Zeit dafür hat.
