Die Sunk Cost Fallacy: Warum es manchmal besser ist, Code wegzuwerfen
Kennst du das Gefühl, an einem Stück Code zu arbeiten, von dem du tief im Inneren weißt, dass er nicht gut ist – unübersichtlich, schwer wartbar oder ineffizient? Trotzdem fällt es schwer, loszulassen, weil bereits viel Zeit und Energie investiert wurden.

Klemens Morbe
Softwareentwickler
Veröffentlicht am
21. Januar 2025

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.
Zitate, die zum Nachdenken anregen
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.
Wie du die Sunk Cost Fallacy erkennst
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?
Professionell mit der Situation umgehen
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:
- 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.
- 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.
- 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?“
Prävention: Wie du die Sunk Cost Fallacy vermeidest
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.
Mut zur Veränderung
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!

Hier schreibt
Klemens Morbe
Als erfahrener Backend-Entwickler mit Schwerpunkt auf Java und Spring bin ich leidenschaftlich für Clean Code und effiziente Softwarearchitekturen.
Meine Expertise teile ich sehr gerne im Unternehmen sowie in Blogartikeln, die über theoretische Konzepte hinausgehen und realitätsnahe Lösungen für den Entwickleralltag bieten.
Durch meine Beiträge möchte ich nicht nur Wissen vermitteln, sondern auch den fachlichen Austausch in der Community fördern und zur stetigen Verbesserung der Softwarequalität beitragen.
Weitere interessante Artikel
Wir möchten hier nicht nur über Neuigkeiten aus dem Unternehmen berichten, sondern auch das Wissen und die Erfahrung unserer Experten teilen.

Die Retrospektive: Mehr als nur ein Ventil für Frust
Die Sprint-Retrospektive ist ein zentraler Bestandteil von Scrum und gibt deinem Team die Möglichkeit, die Zusammenarbeit zu reflektieren und sich kontinuierlich zu verbessern. Doch was passiert, wenn die Erwartungen an die Retro so festgefahren sind, dass ihr eigentlicher Zweck – Lernen und Wachsen – in den Hintergrund rückt? Diese Frage beschäftigt mich immer wieder, da ich als Scrum Master regelmäßig mit unterschiedlichen Bedürfnissen und Vorstellungen innerhalb meines Teams konfrontiert werde.

Klemens Morbe
Softwareentwickler

Matthias Rückblick und wo die Reise hin ging
Homeoffice ist bei pep.digital kein Problem. Für Matthias hat sich das nach einem Jahr pep.digital etabliert. Im Beitrag erzählt er mehr über seinen Weg, wie die Zusammenarbeit mit seinen Kollegen und Kolleginnen bei ihm aussieht und was das Besondere an der parallelen Arbeit für mehrere Kunden ist.
pep.digital