Do you know the feeling of working on a piece of code that you know, deep down, isn’t good? Yet, because you or someone else has already invested a lot of time and energy into it, it’s hard to let go. Instead, the decision is made to keep the code—knowingly accepting technical debt. Welcome to the sunk cost fallacy in software development.
The sunk cost fallacy describes the phenomenon of clinging to already invested resources—whether time, money, or energy—even when a rational decision would suggest otherwise. In programming, it’s especially important to recognize this mental trap and be brave enough to let go of bad code.
Why We Hold On to Bad Code
Perhaps you’ve experienced this yourself: You sit down with a colleague to discuss a part of the code. It’s obvious that the code isn’t good—messy, hard to maintain, or simply inefficient. Yet instead of deleting or rewriting it, the decision is made to keep it. Why? Because it’s already been written. Throwing away the work feels wrong.
This reaction is usually emotional rather than rational. We want to avoid seeing our effort as wasted. But here lies the problem: The time and energy already spent are irrelevant if the code causes more problems than it solves in the long run.
Quotes That Make You Think
A former colleague of mine often quoted Albert Einstein during such discussions:
“Two things are needed for our work: tireless perseverance and the willingness to throw away something into which you have put a lot of time and effort.”
Another quote by Mario Fusco offers a similar perspective:
“The code you write makes you a programmer. The code you delete makes you a good one.”
This statement had a profound impact on me. It takes courage and professionalism to let go of bad code—even if you wrote it yourself. In the end, what matters is not the effort invested but how well the code solves the problem and how easily it can be adapted.
Another quote from Martin Fowler sums it up well:
“The most important property of the code is how easy it is to change.”
And Edsger W. Dijkstra once said:
“The art of programming is the art of organizing complexity, of mastering multitude and avoiding its bastard chaos as effectively as possible.”
These quotes highlight that good code is not an end in itself. It serves to manage complexity and facilitate change—not to justify past investments.
Recognizing the Sunk Cost Fallacy
The first step is becoming aware that you or your team has fallen into this mental trap. Typical signs include statements like:
“But we’ve already worked so much on this!”
“We can’t just throw it away now.”
“It works… somehow.”
When such arguments arise, it’s worth pausing and rationally assessing the situation:
Is the existing code truly the best solution for the problem?
What are the long-term costs (e.g., maintenance or extensions)?
Could starting over save time and effort in the long run?
Handling the Situation Professionally
If you find yourself in such a situation—whether as an affected developer or as a colleague—it often helps to bring the discussion back to a factual level. Here are some tips:
Acknowledge emotions behind decisions: The sunk cost fallacy is an emotional reaction. Addressing and naming it can help make discussions more rational.
Find a compromise: Sometimes keeping parts of the code while rewriting others can be enough to ensure no one feels completely overridden.
Think long-term: Ask questions like: “Will this code still help us in six months?” or “How easy will it be to adapt this code later?”
Prevention: How to Avoid the Sunk Cost Fallacy
While this problem can never be entirely avoided, there are ways to reduce its likelihood:
Seek early feedback: At the start of a story, involve a colleague and discuss together what an ideal solution or implementation might look like. Two minds often think more clearly than one.
Work iteratively: Instead of building large monoliths all at once, work in small steps and regularly review progress.
Reflect regularly: Use retrospectives or personal reviews to critically evaluate your own code.
Courage for Change
Ultimately, it’s about having the courage to let go of bad decisions—even if they’ve cost time and energy. Software development isn’t just about programming; it’s also about reflecting and adapting.
So remember:
“The code you write makes you a programmer. The code you delete makes you a good one.”
Be brave enough to let go of bad code—for yourself, your team, and your project’s future.
How do you handle such situations? Have you ever experienced how hard it can be to let go of bad code? I look forward to hearing your thoughts!
Comments