Die Sunk Cost Fallacy: Warum es manchmal besser ist, Code wegzuwerfen

Dieses Phänomen wird als Sunk Cost Fallacy [1] bezeichnet: Wir klammern uns an bereits investierte Ressourcen wie Zeit, Geld oder Energie, auch wenn eine rationale Entscheidung etwas anderes nahelegen würde. Statt den Code zu löschen oder neu zu schreiben, wird entschieden, ihn zu behalten – oft aus emotionalen Gründen. Doch genau hier liegt das Problem: Die bereits investierte Arbeit ist irrelevant, wenn der Code langfristig mehr Probleme verursacht als löst.

Ein ehemaliger Kollege von mir zitierte in solchen Diskussionen gerne Albert Einstein:

Zwei Dinge sind zu unserer Arbeit nötig: Unermüdliche Ausdauer und die Bereitschaft, etwas, in das man viel Zeit und Arbeit gesteckt hat, wieder wegzuwerfen.

Ein ähnliches Zitat von Mario Fusco zeigt eine ähnliche Sichtweise:

„The code you write makes you a programmer. The code you delete makes you a good one.“

Dieser Satz hat mich besonders geprägt. Es erfordert Mut und Professionalität, schlechten Code loszulassen – auch wenn man ihn selbst geschrieben hat. Denn am Ende zählt nicht die investierte Arbeit, sondern wie gut der Code das Problem löst und wie leicht er sich anpassen lässt.

Ein weiteres Zitat von Fowler bringt es ebenfalls auf den Punkt:

„The most important property of the code is how easy it is to change.“

Und Edsger W. Dijkstra sagte einmal:

„The art of programming is the art of organizing complexity, of mastering multitude and avoiding its bastard chaos as effectively as possible.“

Diese Zitate zeigen: Guter Code ist kein Selbstzweck. Er dient dazu, Komplexität zu beherrschen und Veränderungen zu erleichtern – nicht dazu, vergangene Investitionen zu rechtfertigen.

Der erste Schritt ist, dir bewusst zu machen, dass du oder dein Team in diese Denkfalle geraten seid. Typische Anzeichen dafür sind Sätze wie:

• „Aber wir haben doch schon so viel daran gearbeitet!“
• „Das können wir jetzt nicht einfach wegwerfen.“
• „Es funktioniert doch irgendwie.“

Wenn solche Argumente auftauchen, lohnt es sich innezuhalten und die Situation rational zu betrachten:

• Ist der bestehende Code wirklich die beste Lösung für das Problem?
• Wie hoch sind die langfristigen Kosten (z. B. Wartung oder Erweiterung)?
• Könnte ein Neuanfang langfristig Zeit und Nerven sparen?

Wenn du dich in einer solchen Situation wiederfindest – sei es als betroffener Entwickler oder als Kollege –, hilft es oft, die Diskussion auf eine sachliche Ebene zurückzuführen. Hier ein paar Tipps:

1. Erkenne die Emotionen hinter der Entscheidung: Die Sunk Cost Fallacy ist eine emotionale Reaktion. Wenn du sie ansprichst und benennst, kannst du helfen, die Diskussion rationaler zu gestalten.
2. Finde einen Kompromiss: Manchmal reicht es aus, einen Mittelweg zu finden – z. B. Teile des Codes beizubehalten und andere neu zu schreiben. So fühlt sich niemand komplett übergangen.
3. Denke langfristig: Stelle Fragen wie: „Wird uns dieser Code in sechs Monaten noch helfen?“ oder „Wie leicht wird es sein, diesen Code später anzupassen?“

Natürlich lässt sich dieses Problem nie vollständig vermeiden – aber du kannst das Risiko verringern:

• Hole dir früh Feedback: Ziehe beim Start einer Story einen Kollegen hinzu und besprecht gemeinsam den idealen Ansatz zur Lösung des Problems oder zur Implementierung des Features. Zwei Köpfe denken oft klarer als einer allein.
• Arbeite iterativ: Statt große Monolithen auf einmal zu bauen, arbeite in kleinen Schritten und überprüfe regelmäßig den Fortschritt.
• Führe gewissenhafte Reviews durch: Gute und ernsthafte Code-Reviews sind essenziell, um Probleme frühzeitig zu erkennen und objektiv zu bewerten. Sie helfen dabei, emotionale Entscheidungen zu vermeiden und den Fokus auf die langfristige Qualität des Codes zu legen.
• Reflektiere regelmäßig: Nutze Retrospektiven oder persönliche Reviews, um kritisch auf deinen eigenen Code zurückzublicken. Dabei kannst du auch hinterfragen, ob bestehende Lösungen wirklich die besten sind oder ob Änderungen sinnvoll wären.

Mit diesen Maßnahmen kannst du die Wahrscheinlichkeit verringern, in die Sunk Cost Fallacy zu geraten, und gleichzeitig die Qualität deines Codes langfristig sichern.

Am Ende geht es darum, mutig genug zu sein, schlechte Entscheidungen loszulassen – auch wenn sie Zeit und Energie gekostet haben. Softwareentwicklung bedeutet nicht nur Programmieren; sie bedeutet auch Reflektieren und Anpassen.
Also erinnere dich daran: „The code you write makes you a programmer. The code you delete makes you a good one.“ Sei mutig genug, schlechten Code loszulassen – für dich selbst, dein Team und die Zukunft deines Projekts.
Wie gehst du mit solchen Situationen um? Hast du schon einmal erlebt, wie schwer es sein kann, schlechten Code loszulassen? Ich freue mich auf deine Gedanken!