Bei Legacy-Code schätzt du nicht wie lange etwas dauert. Du schätzt, wie lange es dauert, bis du weißt, wie lange es dauert.
Das klingt nach einer Ausrede. Es ist keine.
Warum Schätzungen immer falsch sind
Golo Roden hat es in seiner „Won't fix!"-Serie auf heise online gut formuliert: Softwareentwicklung ist kein Produktionsprozess. Eine Fabrik die bereits weiß wie man ein Auto baut, kann den Aufwand präzise planen. Wer Software entwickelt, erzeugt erst das Wissen das für die Lösung nötig ist. Das lässt sich nicht im Voraus messen.
Das erklärt warum Schätzfehler kein individuelles Versagen sind. Sie sind eine strukturelle Eigenschaft der Arbeit.
Bei Legacy-Code ist dieses Problem nicht größer – es ist kategorial anders.
Der Unterschied zu Greenfield
Der entscheidende Unterschied ist nicht die Größe der Unsicherheit.
Bei Greenfield-Projekten ist unklar, was gebaut werden soll. Du weißt, wie du bauen kannst – die Unbekannte ist das Was.
Bei Legacy-Code ist auch das Wie unbekannt.
Die Schätzung betrifft deshalb nicht nur die Lösung, sondern zunächst die Problemfindung selbst.
Du öffnest eine Klasse und findest eine God Class. Du folgst einer Abhängigkeit und landest drei Schichten tiefer in einem globalen State. Du änderst eine Zeile und brichst einen Test, der nichts mit deiner Änderung zu tun hat – oder so scheint.
Das ist kein Einzelfall. Das ist das Muster. Jede Änderung an gewachsenem Code beginnt mit einer Erkundung, deren Dauer du nicht schätzen kannst, weil du nicht weißt, was du finden wirst.
Ich habe das selbst erlebt. Zwei Tage Entschlacken einer LimeSurvey-Codebasis – und nach 48 Stunden war klar, dass der initiale Plan unrealistisch war. Nicht weil ich schlecht geschätzt hatte. Sondern weil ich erst nach zwei Tagen wusste was wirklich drin steckte.
Was unter dem nächsten Stein liegt
Das Bild das mir am treffendsten erscheint: Legacy-Code ist wie ein Garten, der seit Jahren nicht gepflegt wurde. Du weißt grob, wie groß er ist. Du weißt, dass Unkraut drin ist. Aber du weißt nicht, ob unter dem Unkraut noch Boden ist – oder ob sich darunter ein Kellerschacht verbirgt, der vor zwanzig Jahren vergessen wurde.
Jeder Stein den du umdrehst kann eine Kleinigkeit darunter haben. Oder ein weiteres System.
Das ist keine Metapher für schlechten Code. Es ist die ehrliche Beschreibung dessen, was in jeder Codebasis passiert, die jahrelang unter echten Bedingungen gewachsen ist – mit wechselnden Entwicklern, wechselnden Anforderungen, wechselndem Zeitdruck.
Und genau darin liegt ein zweites Missverständnis: Viele Legacy-Projekte scheitern an der Vorstellung, man könne den Garten einmal komplett aufräumen und anschließend sei das Problem gelöst. In Wirklichkeit entsteht Wartbarkeit durch kontinuierliche Pflege – denselben Prozess, den wir in der Softwareentwicklung Refactoring nennen.
Wie „Mach mal schnell" beschreibt: die eigentliche Arbeit ist Verstehen, Bewerten, Entscheiden. Das Tippen ist der kleinste Teil. Und bei Legacy-Code beginnt das Verstehen erst wenn man anfängt.
Die Scheingenauigkeit
Organisationen verlangen trotzdem Zahlen. Und Entwickler liefern sie – weil eine Zahl professioneller wirkt als „ich weiß es nicht".
„53 Personentage" klingt nach Analyse. „Zwischen zwei Wochen und drei Monaten" klingt nach Ratlosigkeit.
Dabei ist die zweite Aussage oft die ehrlichere. Sie macht die tatsächliche Unsicherheit sichtbar statt sie zu verstecken.
Das Problem ist nicht, dass Entwickler schlecht schätzen. Das Problem ist dass Organisationen präzise Schätzungen verlangen, wo keine möglich sind – und Entwickler daraufhin Scheingenauigkeit produzieren, die allen schadet.
Was stattdessen geht
Keine Schätzung ist auch keine Antwort. Aber es gibt einen Mittelweg der ehrlicher ist als eine Zahl, die niemand glauben sollte.
Zeitboxen statt Schätzungen. Die erste Schätzung in einem Legacy-Projekt sollte nicht die Umsetzung betreffen, sondern die Erkundung. Die Frage lautet nicht „Wie lange dauert die Änderung?" – sondern „Wie lange investieren wir, um die Risiken sichtbar zu machen?" Das ist kein Entwicklertrick, sondern ein Planungsinstrument: eine Zeitbox, die nicht Aufwand schätzt, sondern Wissen produziert.
Unsicherheit explizit machen. „Wenn keine größeren Überraschungen auftauchen: zwei Wochen. Wenn wir auf das stoßen, was ich befürchte: sechs Wochen." Diese Aussage ist unbequemer als eine Zahl, aber sie beschreibt die Realität.
Früh Erkenntnisse liefern. Die wertvollste Information in einem Legacy-Projekt ist nicht die initiale Schätzung, sondern der erste echte Befund nach zwei Tagen Analyse. Was steckt drin, was ist lösbar, wo sind die echten Risiken.
Fazit
Schätzen im Legacy-Code ist nicht schwieriger als anderswo – es ist strukturell anders. Die Unbekannte ist nicht, nur was gebaut werden soll, sondern was bereits gebaut wurde und wie es zusammenhängt.
Der ehrlichste Satz bleibt: Bei Legacy-Code schätzt du nicht wie lange etwas dauert. Du schätzt, wie lange es dauert, bis du weißt, wie lange es dauert.
Wer das akzeptiert, als Entwickler und als Organisation, plant realistischer, kommuniziert ehrlicher und vermeidet einen großen Teil der klassischen Projektkatastrophen.
Die Alternative ist Scheingenauigkeit. Und die ist teurer als Ehrlichkeit.