The Sunk Cost Fallacy Fallacy

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?

TL;DR

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.