Der wahre Grund, warum Ihr Engineering-Team langsam ist: nicht die Menschen, sondern die Codebasis

• Codebase Drag ist ein Zustand der Codebasis, in dem jede Arbeit länger dauert als nötig. Da dies in Dashboards oder Sprint-Reports nicht sichtbar wird, entsteht ein Teufelskreis, in dem die Führungsebene das Problem als "Personalproblem" missversteht.
• Aus Audits von Codebasen über viele Jahre hinweg tauchten immer wieder dieselben fünf Signale auf; daraus wurde mit dem "Codebase-Drag-Audit" eine diagnostische Rubrik vorgeschlagen, die diese mit 0 bis 2 Punkten quantifiziert.
• Aufgeblähte Schätzungen, Angst vor Deployments, Dateien, die man nicht anfassen soll, Coverage-Lügen und die Zeit bis zum ersten Commit sind allesamt Signale von Problemen in der Codebasis und von mangelnder individueller Leistungsfähigkeit zu unterscheiden.
• Je erfahrener ein Engineer ist, desto besser erkennt er die Risiken der Codebasis und bewegt sich entsprechend vorsichtiger, wodurch das paradoxe Bild entsteht, sogar langsamer zu wirken. Wenn man das fälschlich als Talentproblem deutet, führt das kontraproduktiv nur zu mehr Prozessen.
• Ab 4 Punkten sind direkte Investitionen in die Codebasis nötig, ab 7 Punkten ist ein sofortiger struktureller Eingriff erforderlich.

---

Was ist Codebase Drag?

• Codebase Drag bezeichnet das Phänomen, dass die Codebasis jede Arbeit länger dauern lässt als nötig; in Sprint-Reports oder Dashboards taucht das nicht auf.
  • Beispiel: Ein Client-Team verbrauchte mit 2 Engineers eine Woche, um im Admin-Panel eine CSV-Exportfunktion hinzuzufügen — die eigentliche Arbeit entsprach nur einem Tag, die restliche Zeit ging für das Verständnis drauf, das nötig war, um bestehenden Code sicher zu ändern.
• Wenn sich Verlangsamungen im Teamtempo wiederholen, wertet die Führung dies als Talentproblem und reagiert mit Reorganisation, zusätzlichen Prozessen oder Personalaustausch — doch auch das nächste Team stößt auf dieselbe Wand.
• Die eigentliche Ursache sind weder Bugs noch fehlende Features noch das, was man üblicherweise als Technical Debt bezeichnet, sondern die Codebasis selbst.

Fünf Signale für Codebase Drag

1. Entschuldigende Schätzung (Apology Estimate)

• Gemeint ist die Situation, dass ein Engineer für ein Feature, das eigentlich 3 Tage dauert, 2 Wochen veranschlagt; die Führung deutet das fälschlich als aufgeblähte Terminplanung.
• Der wahre Grund ist Kopplung zwischen Modulen, etwa wenn eine Änderung am Billing-Modul auch das Notification-System berührt, sowie eine Struktur, in der unklar ist, wie weit die Auswirkungen einer Änderung reichen.
  • Durch hidden default scope oder tief verschachtelte Callbacks lässt sich der blast radius einer Änderung nicht vorhersagen, ohne die Hälfte des Codes zu lesen.
• Wenn Schätzungen durchgängig 2- bis 3-mal länger dauern als erwartet, ist das kein Problem der Schätzung, sondern ein Kostenproblem der Codebasis.

2. Angst vor Deployments (Deploy Fear)

• Es zeigt sich ein Muster, bei dem Teams Deployments am Freitag meiden oder Änderungen bündeln und nur selten in großen Releases ausliefern.
• Ein Client-Team hatte die informelle Regel, nach Mittwoch nicht mehr zu deployen — entstanden nach drei Donnerstag-Deployments, die zu Wochenend-Störungen führten.
  • Ursache waren fehlende Rollback-Strategien, unzuverlässige Tests und eine 45 Minuten lange Deployment-Pipeline.
• Nach DORA deployen Elite-Teams bei einer Change-Failure-Rate von unter 5 % bei Bedarf sofort; dieses Team dagegen deployte nur einmal pro Woche und wartete dabei angespannt ab.

3. Die Datei, die man nicht anfassen darf (Don't Touch That File)

• In fast jedem Einsatz fällt innerhalb der ersten zwei Tage der Satz: "Diese Datei solltest du nicht anfassen."
  • Etwa ein Billing-Controller mit 30 before_action, oder ein Modell, das oben in git log auftaucht, strukturell aber seit Jahren nicht wirklich angefasst wurde.
• Wenn man git log --oneline --since="2 years ago" ausführt, ist die am häufigsten geänderte Datei immer genau die Datei, vor der gewarnt wurde — wenn sich dort nur kleine Patches häufen und keine strukturelle Arbeit stattfindet, werden nur Symptome behandelt und die Krankheit bleibt bestehen.
• Die eigentlichen Kosten bestehen darin, dass Funktionen, die in dieses Modul gehören, anderswo implementiert werden; neue Mitarbeitende lernen schon in der ersten Woche, diese Datei zu meiden — die Codebasis wächst dadurch missgebildet um tote Zonen herum.

4. Die Coverage-Lüge (Coverage Lie)

• Eine Zahl wie 80 % Test-Coverage wirkt gesund, tatsächlich tragen aber oft Tests für Serializer, Helper und Utilities, die kaum jemals brechen, diese Quote, während drei zentrale Modelle, die mit Geld umgehen, gar nicht getestet sind.
• Die Test-Suite dient dann nicht dazu, Regressionen zu erkennen, sondern dazu, die Kennzahl gut aussehen zu lassen — Tests laufen grün, aber Production bricht trotzdem.
• Wenn CI 40 Minuten dauert, hören Entwickler auf, Tests lokal auszuführen → die Coverage-Zahl lügt in zweierlei Hinsicht: Sie deckt die wichtigen Teile nicht ab, und selbst die vorhandenen Tests werden nicht ausgeführt.
• Die eigentliche Frage ist nicht die Coverage-Zahl, sondern: "Wann hat ein Test zuletzt einen Bug vor Production abgefangen?"

5. Zeit bis zum ersten Commit (Time to First Commit)

• Gemeint ist die Zeit vom Aushändigen des Laptops an einen neuen Engineer bis zum Öffnen eines PR mit einem echten Bugfix oder einem kleinen Feature.
  • Gesunde Codebasis: 1–2 Tage
  • Codebasis mit Drag: 2 Wochen oder mehr
• Bei einem Client dauerte das Aufsetzen der Entwicklungsumgebung mehrere Wochen; nach einer Überarbeitung konnten neue Entwickler ihre Umgebung in 15–20 Minuten einrichten.
• Hauptursache ist setup rot — das bin/setup-Skript wurde seit der letzten Umgebungsänderung nicht aktualisiert, Seed-Daten verweisen auf Tabellen oder Spalten, die nicht mehr existieren, und drei undokumentierte Umgebungsvariablen fallen erst durch Abstürze beim Start der App auf.
• Bestehende Engineers haben die undokumentierten Abläufe bereits internalisiert; nur neue Mitarbeitende zeigen deshalb präzise, wie viel implizites Wissen die Codebasis voraussetzt.

Warum gute Engineers in einer schlechten Codebasis langsam wirken

• Die fünf Signale wirken zusammengenommen und fügen jeder Aufgabe Overhead hinzu, den man im Standup keinem Einzelpunkt zuordnen kann.
  • Ein Engineer, der im vorherigen Job ein Feature in zwei Tagen umgesetzt hätte, braucht in dieser Codebasis eine Woche — und wenn er den Grund erklären will, klingt es wie eine Ausrede.
• Laut einer METR-Studie von 2025 waren erfahrene Entwickler beim Einsatz von AI-Tools 19 % langsamer — ein Hinweis darauf, dass nicht das Tippen der Engpass war.
• Je besser die Engineers sind, desto eher erkennen sie Risiken und bewegen sich vorsichtiger, planen also konservativ — weniger erfahrene Engineers sehen die Risiken nicht, deployen schneller und verursachen dann Production-Störungen, woraufhin das ganze Team noch vorsichtiger wird.
• Ein Client tauschte in zehn Jahren 6 Teams aus, darunter 2 vollständige Übernahmen — das Muster wiederholte sich stets: Feature-Druck durch die Führung → Schuldenabbau wird übersprungen → der Code wird irreparabel → Rewrite oder Extraktion in Microservices wird vorgeschlagen → das System verdoppelt sich und wird noch schlimmer.
• Wenn die Führung Verlangsamung als Talentproblem liest, fügt sie einem ohnehin schon von Reibung geplagten Team nur noch mehr Prozesse hinzu — der einzige Eingriff, der wirklich hilft, ist, den Pfad selbst zu korrigieren.

Das Codebase-Drag-Audit: So wird diagnostiziert

• Jedes der fünf Signale wird mit 0 bis 2 Punkten bewertet:
  • 0 Punkte: kein Problem
  • 1 Punkt: teilweises Problem
  • 2 Punkte: schwerwiegendes Problem
• Bei 4 Punkten oder mehr sollte jede andere Maßnahme hinter direkten Investitionen in die Codebasis zurückstehen.

Was tun, wenn Technical Debt das Team bremst?

• Mit dem am höchsten bewerteten Signal beginnen — nicht versuchen, alles gleichzeitig zu beheben.
  • 2 Punkte bei Deployment-Angst: zuerst CI-Geschwindigkeit, Rollback-Automatisierung und kleinere Deployment-Einheiten verbessern
  • Platz 1 bei entschuldigender Schätzung: zuerst das Modul mit dem größten blast radius entkoppeln
  • 2 Punkte bei Zeit bis zum ersten Commit: Ein Tag Investition in bin/setup und Umgebungsdokumentation zahlt sich bei jeder zukünftigen Einstellung wieder aus
• Wenn die Rails-Version mehrere Versionen zurückliegt, kann ein Versions-Upgrade als forcing function dienen, die die Investition rechtfertigt.
• Im Zwei-Wochen-Rhythmus messen: Signal mit Höchstwert auswählen → fokussierter Sprint → konkrete Kennzahlen messen (Deployment-Frequenz, Genauigkeit von Schätzungen, Zeit bis zum ersten PR usw.)
• Investitionen lassen sich schwer genehmigen, weil die Kosten des Nichtstuns unsichtbar sind — statt "Wir haben Technical Debt" überzeugt die Aussage "Durch die Kopplung dieser drei Module dauert jedes Feature ungefähr doppelt so lange" deutlich mehr.
• 7 Punkte oder mehr bedeuten im Allgemeinen ein Niveau, bei dem man mit einem einwöchigen Codebase-Audit beginnen sollte.

[mbh023]

Stimmt echt, Legacy-Projekte sind eine echte Plage
Es gibt Dinge, die es nicht mal wert sind, neu gemacht zu werden – da wäre es besser, gleich von vorn anzufangen.

[hanje3765]

Geht es um mich ..?

[maedk10]

Das scheint ein wirklich wichtiger Beitrag zu sein, wenn es darum geht, die Wartungskosten zu senken.

[cronex]

Deshalb kommt es manchmal vor, dass es schneller ist, es neu zu schreiben.

[kallare]

Jeder weiß, dass das Aufräumen der Codebasis langfristig der Weg zu mehr Geschwindigkeit ist,
aber das ist ungefähr so eine Binsenweisheit wie die, dass man gesünder wird, wenn man gut isst, Sport treibt und genug schläft.