The Sunk Cost Fallacy Fallacy

19 Nov, 2015

Imagine two football fans planning to attend a match 60 miles away. One of them paid for a ticket in advance; the other was just about to buy a ticket when he got one from a friend for free. The night of the game, a blizzard hits. Which fan do you think is more likely to drive through a blizzard to see the game?
You probably (correctly) guessed that the fan who paid for his ticket is more likely to drive through the blizzard. What you may not have realized, though, is that this is an irrational decision, at least economically speaking.

The football fan story is a classic example of the Sunk Cost Fallacy, adapted from Richard Thaler’s “Towards a Positive Theory of Consumer” (1980) in Daniel Kahneman’s excellent book, “Thinking, Fast and Slow” (2011).  Many thanks to my colleagues Joshua Appelman, Viktor Clerc and Bulat Yaminov for the recommendations.

The Sunk Cost Fallacy

The Sunk Cost Fallacy is a faulty pattern of behavior in which past investments cloud our judgment on how to move forward. When past investments are irrecoverable (we call them ‘sunk’ costs, and they should have no effect on our choices for the future. In practice, however, we find it difficult to cut our losses — even when it’s the rational thing to do.
We see the Sunk Cost Fallacy effect in action every day when evaluating technical and business decisions. For instance, you may recognize a tendency to become attached to an “elegant” abstraction or invariant, even when evidence is mounting that it does the overall complexity more harm than good. Perhaps you’ve seen a Product Owner who remains too attached to a particular feature, even after its proven failure to achieve the desired effect. Or the team that sticks to an in-house graphing library even after better ones become available for free, because they are too emotional about throwing out their own code.
This is the Sunk Cost Fallacy in action. It’s healthy to take a step back and see if it’s time to cut your losses.

Abuse of the Sunk Cost Fallacy

However, the Sunk Cost Fallacy can be abused when it’s used as an excuse to freely backtrack on choices with little regard for past costs. I call this the Sunk Cost Fallacy Fallacy.
Should you move from framework A to framework B? If B will help you be more effective in the future, even when you’ve invested in A, the Sunk Cost Fallacy says you should move to B. However, don’t forget to factor in the ‘cost of switching’: the past investments in framework A may be sunk costs, but switching could introduce a technical debt of code that needs to now be ported. Make sure to compare the expected gain against this cost, and make a rational decision.
You might feel bad about having picked framework A in the first place. The Sunk Cost Fallacy teaches you not to let this emotion cloud your judgment while evaluating framework B. However, it is still a useful emotion that can trigger valuable questions: Could you have seen this coming? Is there something you could have done in the past to make it cheaper to move from framework A to framework B now? Can you learn from this experience and make a better initial choice next time?


An awareness of the Sunk Cost Fallacy can help you make better decisions: cut your losses when it is the rational thing to do. Be careful not to use the Sunk Cost Fallacy as an excuse, and take into account the cost of switching. Most importantly, look for opportunities to learn from your mistakes.

Newest Most Voted
Inline Feedbacks
View all comments
Chris Lukassen
Chris Lukassen
6 years ago

Excellent post (of course for software systems 🙂 but indeed it’s switching cost we need to consider!
Thanks a lot will steal your example shamelessly 🙂

Arnout Engelen
Arnout Engelen
6 years ago
Reply to  Chris Lukassen

Thanks – steal away!
Indeed the switching cost needs to be considered – and it needs to be considered fairly: I see it both being over-estimated (for example due to the Sunk Cost Fallacy) and under-estimated (for example due to the effect described above).
The only way to get better is to be aware of the choice, make the best decision you can, and then learn from the results. The tricky bit is of course that you can’t really know how things would have played out if you made the other choice – but at least you can compare against your expected outcome.

Andriy Mudryy
Andriy Mudryy
6 years ago

Great post!
This was my introduction to Sunk Cost Fallacy. Need to read more about it.
At least I know the term and can refer to it when needed.
Plus, this is post is a starting point for further investigation.

Luuk Dijkhuis
Luuk Dijkhuis
6 years ago

so true. Especially in framework land where just about the entire global developer community seems to find it necessary to come up with yet another better framework on a monthly basis (kudos for the energy, but can we please just focus on improving something existing?), there is always a new horizon where code will be so much better. LET’S PORT ALL THE THINGS!
Let’s not

Andrew Phillips
Andrew Phillips
6 years ago
Reply to  Luuk Dijkhuis

A.k.a. “Fear-of-missing-out driven development”? 😉

Explore related posts