“Es richtig neu zu schreiben, würde bedeuten zuzugeben, dass ich es nicht einfach reparieren kann”

Der Flicken als DeckmantelDu steckst schon im dritten Flicken für dasselbe Abrechnungsmodul, wieder ein try/catch um eine Funktion gewickelt, der niemand traut, und der Gedanke, der dich stoppt, ist nicht 'das braucht einen Rewrite'. Es ist, dass dieser Satz laut ausgesprochen bedeuten würde zuzugeben, dass die Flicken nie halten sollten. Also glaubst du weiter den Mythos: einen Rewrite vorzuschlagen heißt zuzugeben, dass du persönlich nicht einfach reparieren konntest, was da war, also ist ein weiterer Flicken der sichere Weg.

Warum sich der Rewrite wie ein Geständnis anfühltDer Mechanismus ist Verankerung: in dem Moment, als du dieses Modul geerbt hast, wurde 'vor Ort reparieren' dein Standardrahmen, und jeder Flicken seither hat diesen Rahmen als den einzig akzeptablen bestärkt. Jetzt einen Rewrite zu benennen würde bedeuten, aus dem Rahmen auszutreten, an dem du dich am ersten Tag verankert hast — nicht weil der Code dagegenspricht, sondern weil ein Rahmenwechsel sich anfühlt wie das Rückgängigmachen einer Entscheidung, die du nie bewusst getroffen hast.

Die private Zwei-Spalten-ProbeNimm dir vor dem nächsten Flicken fünf Minuten für eine private Liste mit zwei Spalten: eine für Teile, die du wirklich vor Ort reparieren könntest, eine für Teile, die du nur als 'muss neu geschrieben werden' beschreiben würdest. Niemand sieht sie. Bleibt die zweite Spalte kurz, hält der Mythos vorerst stand. Wächst sie jedes Mal, wenn du hinschaust, ist das eine Information, die dir der nächste Flicken allein nicht liefert.