Technische Schulden anhand echter Beispiele aus Mittelstandssystemen erklärt

Die meisten Artikel über technische Schulden bleiben abstrakt. Sie sprechen von „angesammelten Abkürzungen" und „sich verstärkendem Risiko", ohne je zu zeigen, wie das in einem echten Unternehmen tatsächlich aussieht. Die folgenden Beispiele für technische Schulden stammen aus fünf mittelständischen europäischen Unternehmen, größtenteils deutschen Mittelstandsfirmen, deren identifizierende Merkmale entfernt wurden. Jedes zeigt eine konkrete Entscheidung, was sie später gekostet hat, und was nötig war, um sie zu beheben.

Das allgemeine Framework zur Messung und Kommunikation technischer Schulden haben wir in einem früheren Beitrag behandelt. Dieser Beitrag überspringt das Framework und geht direkt zu den Fällen.

Fünf Beispiele für technische Schulden mit echten Zahlen

Bei den folgenden Unternehmen handelt es sich größtenteils um deutsche Mittelstandsfirmen, gemischt mit ein paar SaaS-Unternehmen, denn das Muster ist nicht spezifisch für die Fertigungsindustrie oder für Deutschland. Was sie gemeinsam haben, ist eine lange Lücke zwischen der Abkürzung und der Rechnung. In jedem Fall wirkte die Entscheidung, die die Schulden verursachte, zum damaligen Zeitpunkt harmlos, und die Kosten wurden erst sichtbar, als etwas von außen die Sache erzwang: eine wachsende Kundenbasis, ein Audit oder ein Ausfall.

Beispiel 1: Das Bestellsystem, das niemand anfassen konnte

Ein familiengeführter Fertigungszulieferer baute sein Bestellsystem 2011 auf einem PHP-Framework auf, das bereits 2015 als veraltet galt. Der ursprüngliche Entwickler verließ das Unternehmen 2017. Niemand, der blieb, verstand die Codebasis gut genug, um Änderungen mit Zuversicht vorzunehmen, sodass jede neue Anforderung als Workaround angeflanscht wurde, statt als ordentliche Änderung umgesetzt zu werden.

Bis 2024 hatte das System ein Dutzend Sonderfall-Zweige für einzelne Kunden angesammelt, jeweils hartcodiert statt konfiguriert. Eine einzelne Preisregeländerung für einen Kunden dauerte drei Wochen statt des halben Tages, den sie hätte dauern sollen, weil der Entwickler sich durch undokumentierte Logik arbeiten musste, um jede Stelle zu finden, an der die alte Regel referenziert wurde.

Das Unternehmen bezahlte schließlich für eine komplette Neufassung der Preis- und Bestelllogik. Das Projekt kostete etwa vier Monate Entwicklerzeit eines Senior-Entwicklers, für ein System, das bei korrekter Umsetzung von Anfang an zwei Wochen gebraucht hätte. Die eigentlichen Kosten waren nicht die Neufassung. Es waren die acht Jahre langsamer, teurer Änderungen, die ihr vorausgingen, plus die Tatsache, dass das Vertriebsteam während dieser Zeit zweimal falsche Preise anbot, weil niemand verifizieren konnte, dass die Regel korrekt angewendet wurde.

Beispiel 2: Die Authentifizierungs-Abkürzung, die zum Compliance-Problem wurde

Ein Healthtech-Unternehmen, das ein Patientenportal baute, musste schnell für einen Pilotkunden launchen. Das Team verdrahtete die Authentifizierung direkt in die Hauptanwendung, statt einen separaten Identitätsdienst zu nutzen, mit der Begründung, man würde das „später richtig lösen", sobald sich der Pilot bewährt hätte.

Der Pilot war erfolgreich. Das Unternehmen gewann drei weitere Kunden. Jeder neue Kunde brauchte leicht abweichende Authentifizierungsregeln, und jede Regel wurde demselben verworrenen Codeblock hinzugefügt. Als das Unternehmen zwei Jahre später die ISO-27001-Zertifizierung beantragte, markierte der Auditor das Authentifizierungssystem als Single Point of Failure ohne klares Zugriffskontrollmodell.

Die Authentifizierung in einen eigenen Dienst auszugliedern, was am Anfang ein Zwei-Wochen-Projekt gewesen wäre, dauerte unter dem Druck der Zertifizierungsdeadline sechs Wochen, bei dem das gesamte Entwicklungsteam von anderer Arbeit abgezogen wurde. Die Verzögerung der Zertifizierung verschob einen bereits unterschriebenen Enterprise-Vertrag um ein ganzes Quartal.

Beispiel 3: Die Tabelle, die zur Datenbank wurde

Ein Logistikunternehmen erfasste Sendungsausnahmen in einer geteilten Tabelle, weil das System des ursprünglichen Softwareanbieters den spezifischen Workflow, den das Operations-Team brauchte, nicht unterstützte. Die Tabelle funktionierte problemlos mit zwölf Nutzern. Als vierzig Personen damit arbeiteten, waren Versionskonflikte und stille Überschreibungen ein wöchentliches Ereignis.

Niemand hatte ein ordentliches Ausnahmemodul budgetiert, weil die Tabelle nie als dauerhafte Lösung gedacht war. Sie lief seit vier Jahren. Die eventuelle Lösung, ein dediziertes internes Tool mit ordentlicher Nebenläufigkeitsbehandlung, brauchte zehn Wochen zum Bauen. Der Business Case stand nie in Frage. Das Problem war, dass die Entscheidung immer wieder aufgeschoben wurde, weil die Tabelle technisch noch funktionierte, bis eine doppelt gebuchte Sendung eine Kundenbeschwerde auslöste, die den Vorstand erreichte.

Beispiel 4: Die Abhängigkeit, die niemand zu aktualisieren wagte

Ein SaaS-Unternehmen aus der Baubranche betrieb sein Backend auf einer Framework-Hauptversion, die drei Major-Releases hinter der aktuellen lag. Das Team wusste von der Lücke. Man vermied das Update zwei Jahre lang, weil der letzte Versuch, ohne ausreichende Testabdeckung durchgeführt, die Produktion sechs Stunden lang lahmgelegt und einen sichtbaren Kundenausfall verursacht hatte.

Als eine kritische Sicherheitslücke in einer Abhängigkeit bekannt wurde, die die alte Framework-Version benötigte, hatte das Unternehmen keinen sicheren Weg, sie zu patchen, ohne das vollständige Upgrade durchzuführen. Das Upgrade, sauber durchgeführt mit gestaffeltem Rollout und einer speziell für die Migration gebauten Testsuite, dauerte elf Wochen. Dasselbe Upgrade schrittweise durchzuführen, eine Version nach der anderen bei jedem Release, hätte verteilt etwa zwei Wochen pro Jahr gekostet, bei deutlich geringerem Risiko in jedem einzelnen Schritt.

Das ist das deutlichste Muster über alle fünf Fälle hinweg: Aufgeschobene Wartung bleibt nicht konstant. Sie wächst exponentiell, und die Höhe der letztendlichen Rechnung folgt fast genau der Zeit, die das Unternehmen gewartet hat.

Beispiel 5: Das Reporting-Feature, das dreimal gebaut wurde

Ein B2B-Abonnementunternehmen brauchte Nutzungsreporting für seine größten Kunden. Die erste Version wurde schnell von einem Freelancer gebaut, der kurz darauf das Unternehmen verließ. Das zweite Team, das den Ansatz des Freelancers nicht verstand, baute es von Grund auf neu, statt es zu erweitern. Achtzehn Monate später wiederholte ein drittes Team das Muster aus demselben Grund.

Drei Bauten im Wesentlichen desselben Features, jeder löste dasselbe Geschäftsproblem, das die vorherige Version schon gelöst hatte, kosteten das Unternehmen in Summe mehr, als eine einzige gut spezifizierte Version gekostet hätte, selbst mit einem großzügigen Budget für die Anforderungserhebung vorab. Die eigentliche Ursache war kein Mangel an Entwicklerkompetenz. Es war ein Mangel an Dokumentation und architektonischer Kontinuität zwischen den Teams, was dazu führte, dass jeder neue Entwickler den bestehenden Code als nicht erhaltbar betrachtete, statt als Ausgangspunkt.

Was diese Fälle gemeinsam haben

Keinem dieser Unternehmen fehlte es an kompetenten Entwicklern. Keines traf zum damaligen Zeitpunkt eine offensichtlich leichtsinnige Entscheidung. Jede Abkürzung war angesichts der Informationslage und des Zeitdrucks im jeweiligen Moment nachvollziehbar. Die Schulden häuften sich an, weil niemand sie als eigenen Posten erfasste, sodass sie für diejenigen unsichtbar blieben, die sie priorisiert hätten abbauen können, bis eine Deadline, ein Audit oder ein Ausfall die Sache erzwang.

Eine nützliche Gewohnheit für jede nicht-technische Führungskraft, die ein Softwareteam leitet: Bitten Sie um eine kurze Liste der drei größten Workarounds, die derzeit produktiv laufen, und was passieren würde, wenn sich Traffic oder Kundenzahl verdoppeln. Kann das Entwicklungsteam diese Frage nicht schnell beantworten, sammeln sich die Schulden irgendwo an, wo sie nicht erfasst werden.

Es hilft auch zu fragen, wann jeder Workaround eigentlich behoben werden sollte. In vier der fünf oben genannten Fälle wusste jemand im Team bereits, dass die Abkürzung temporär war, und sagte das auch zum damaligen Zeitpunkt. Die Behebung wurde nie eingeplant, weil nichts im Kalender sie erzwang, und eine Aufgabe ohne Deadline verliert tendenziell jede Planungssitzung gegen eine Aufgabe, die eine hat. Die Behebung als terminierte Verpflichtung zu behandeln, selbst eine lose, reicht oft aus, um zu verhindern, dass Schulden über Jahre unangetastet liegen bleiben.

Wir helfen Unternehmen genau in dieser Situation, meist nach einem Beinahe-Unfall wie den oben beschriebenen, durch Legacy-Code-Optimierung und laufende Code-Qualitätsberatung, die diese Muster erkennt, bevor sie zu einer sechsstelligen Neufassung werden. Wenn Ihnen eines der fünf obigen Beispiele bekannt vorkommt, lohnt sich ein Gespräch, bevor die nächste Deadline oder das nächste Audit die Entscheidung erzwingt.

Melden Sie sich unter hello@wolf-tech.io oder besuchen Sie wolf-tech.io, um zu besprechen, was sich in Ihrer eigenen Codebasis ansammelt.