Throwing Good Money After Bad
You buy a movie ticket for $15. Thirty minutes in, the movie is terrible. Do you leave or stay? Most people stay — "I already paid $15." But the $15 is gone whether you stay or leave. The only question is: "Is sitting through 90 more minutes of a bad movie the best use of my next 90 minutes?" The answer is almost certainly no. Yet we stay, because abandoning the movie feels like "wasting" the $15, even though staying wastes something more valuable: your time.
The Sunk Cost Fallacy is the tendency to continue investing in something because of previously invested resources (time, money, effort, emotional energy), even when the future costs outweigh the future benefits. The past investment is "sunk" — it cannot be recovered regardless of what you do next. Rational decisions should be based only on future costs and future benefits.
The Logic Trap in Engineering
"We can't abandon this migration to Kubernetes now! We've spent 8 months on it!"
Reframe: The 8 months are gone. They are irrecoverable whether you continue or stop. The only question that matters is: "From today forward, what is the best use of the next 12 months?" If finishing the migration will take another 12 months of pain for marginal gain, and the team could instead spend those 12 months on features that directly impact revenue, stopping is the rational choice. The 8 months are not "wasted" by stopping — they are equally gone either way.
Why It's So Hard to Stop
- Ego attachment: Engineers identify with their work. Killing a project feels like admitting failure. ("I spent 8 months on something worthless.")
- Organizational inertia: Managers who approved the budget don't want to explain to leadership why they "wasted" resources.
- Escalation of commitment: Each additional investment makes the next one feel more justified. "We've spent 8 months, what's one more?" becomes "We've spent 14 months, what's one more?" This is how 6-month projects become 3-year death marches.
Real-World Engineering Examples
- A team spends 4 months building a custom monitoring solution. Grafana Cloud releases a feature that does 90% of what they built. The team continues building "because we're almost done" — but "almost done" means 3 more months of development plus ongoing maintenance forever.
- A company chose a NoSQL database 2 years ago. It's now clear that the data is highly relational and the team spends 40% of their time working around the lack of joins. But migrating to PostgreSQL "would waste the 2 years we invested in the NoSQL schema."
- An engineer refactors a module for 3 weeks. On day 15, they realize the approach is fundamentally flawed. Instead of starting over with a better design (2 days of work), they spend 2 more weeks patching the flawed approach into something that "works" but is fragile and will need to be replaced anyway.
The Fix — Process Patches
- Kill Criteria Up Front: Before starting any project longer than 2 weeks, define explicit conditions under which the project should be abandoned. Write them down. "If by week 6 we cannot demonstrate X, we stop." This removes the emotional decision from the moment of crisis and makes stopping feel like executing a plan rather than admitting defeat.
- Pre-Mortems: Before starting, imagine the project has failed. Ask: "What killed it?" This surfaces risks early and makes future abandonment feel like executing a plan rather than admitting defeat.
- Reframe the Language: Stop saying "We wasted 8 months." Say "We invested 8 months in learning that this approach doesn't work. That knowledge is valuable. Now we can make a better decision." This isn't spin — it's accurate. Failed experiments produce data. The data has value even when the project doesn't.
Key Point: The sunk cost fallacy is the #1 reason bad legacy refactors drag on for years and zombie projects consume team capacity. Senior engineers distinguish themselves by their willingness to kill their own work when the evidence demands it. In an interview, if asked about a project that failed, describing how you decided to stop and why demonstrates more engineering maturity than describing how you pushed through to a mediocre finish.