Scrolls
4 min read
On this page

Sunk Cost & Confirmation Bias

Two of the most destructive cognitive biases in engineering are sunk cost fallacy and confirmation bias. They are destructive precisely because they are invisible in the moment. Sunk cost makes you continue investing in a failing approach because you have already invested so much. Confirmation bias makes you seek evidence that your approach is correct rather than evidence that it is wrong. Together, they create a feedback loop: sunk cost keeps you on the path, and confirmation bias prevents you from seeing that the path is wrong.

Sunk Cost Fallacy

The sunk cost fallacy is the tendency to continue an endeavor because of previously invested resources (time, money, effort) that cannot be recovered. The rational approach is to evaluate future actions based only on future costs and future benefits. What you have already spent is gone regardless of what you do next.

The fallacy in action:

  "We have spent 6 months building this custom ORM.
   We cannot switch to an existing solution now."

  The 6 months are gone whether you switch or not.
  The only question is: going forward, which option
  produces better outcomes?

  Option A: Continue custom ORM
    Future cost: 4 more months + ongoing maintenance forever
    Future benefit: Custom solution, exactly fits your needs

  Option B: Switch to existing ORM
    Future cost: 2 months migration + learning curve
    Future benefit: Maintained by community, battle-tested

  If Option B is better for the future, switch.
  The 6 months spent are irrelevant to this decision.

Engineering Examples of Sunk Cost

Architecture decisions:
  "We picked microservices 18 months ago and invested heavily.
   We are seeing problems but cannot go back to a monolith."

  Can you? 18 months of microservices work does not obligate
  you to continue. If a monolith serves you better going
  forward, the switch is worth analyzing on its own merits.

Technology choices:
  "We wrote 50,000 lines of Java. Rewriting in Go would
   mean throwing all that away."

  The 50,000 lines exist regardless. The question is whether
  maintaining 50,000 lines of Java or rewriting in Go produces
  better outcomes over the next 3 years. Sometimes the answer
  is to keep Java. But the sunk cost should not be the reason.

Feature development:
  "We have been building this feature for 3 sprints.
   It is not working as expected but we are almost done."

  "Almost done" with a feature that does not work is not
  progress. If the feature will not deliver value, stopping
  now saves the remaining effort. The 3 sprints are gone.

Hiring:
  "We spent 2 months training this person. They are not
   performing but we have invested so much in them."

  The 2 months of training are sunk. The question is:
  will this person succeed going forward? If not, continuing
  to invest is throwing good money after bad.

Why Sunk Cost Is So Powerful

Sunk cost is powerful because it triggers loss aversion. Abandoning a project feels like losing the investment. But the investment is already lost — the only question is whether you will also lose the future investment.

Psychological framing:

  Continuing: "We are building on our investment"
  (Feels like protecting value)

  Stopping: "We are throwing away 6 months of work"
  (Feels like destroying value)

  Reality: The 6 months are gone either way.
  Continuing adds cost. Stopping saves future cost.
  But stopping feels worse because humans hate loss.

Confirmation Bias

Confirmation bias is the tendency to search for, interpret, and remember information that confirms your existing beliefs. In engineering, this means you Google to prove your architecture choice was right, not to test whether it was right. You interpret ambiguous evidence as supporting your position. You remember the successes of your chosen technology and forget the failures.

The bias in action:

  You chose React for the frontend.
  When evaluating the decision later:

  Confirmation bias:
    - You read articles praising React
    - You dismiss complaints about React as "skill issues"
    - You attribute successes to React ("good component model")
    - You attribute failures to other factors ("bad API design")

  Objective evaluation:
    - You read both positive and negative React experiences
    - You consider whether complaints apply to your use case
    - You attribute successes and failures to their actual causes
    - You compare outcomes with what another choice might have produced

Engineering Examples of Confirmation Bias

Code reviews:
  You wrote the code. You review your own PR before submitting.
  You are looking for reasons it is correct, not reasons it is wrong.
  You skim through the happy path and skip the edge cases.
  This is confirmation bias applied to your own work.

Architecture reviews:
  You proposed the architecture. During the review, you:
  - Emphasize the strengths of your design
  - Downplay the weaknesses
  - Interpret questions as attacks rather than genuine inquiry
  - Cherry-pick comparison points that favor your approach

Debugging:
  You have a hypothesis about the bug. You:
  - Write tests that confirm your hypothesis
  - Ignore log lines that contradict it
  - Interpret ambiguous evidence as supporting your theory
  - Stop investigating when you find one piece of confirming evidence

  The fix: write tests that would DISPROVE your hypothesis.
  If they pass, your hypothesis is wrong.

Technology evaluation:
  You already want to use Kubernetes. You:
  - Read case studies from companies that succeeded with K8s
  - Skip articles about K8s failures
  - Weight the opinions of K8s advocates more heavily
  - Dismiss concerns as "we will figure it out"

Confirmation Bias in Data Interpretation

A/B test results:
  New feature shows 2% improvement, p-value 0.08.

  With confirmation bias (you built the feature):
    "Almost significant! With more data it would be.
     Let us ship it."

  Without confirmation bias:
    "Not statistically significant. The improvement could
     be noise. We need more data or should consider that
     the feature may not be effective."

Performance metrics:
  You optimized a function. Benchmarks show 5% improvement.

  With confirmation bias:
    "See, the optimization worked!"

  Without confirmation bias:
    "Is 5% within measurement noise? Did I benchmark
     under realistic conditions? Did the optimization
     have side effects elsewhere?"

The Feedback Loop Between Sunk Cost & Confirmation Bias

These biases reinforce each other in dangerous ways:

Month 1: Choose approach X
Month 3: Spend 3 months building approach X (sunk cost accumulates)
Month 4: First signs of problems
  - Sunk cost says: "We have invested 3 months, keep going"
  - Confirmation bias says: "These problems are normal,
    all approaches have issues early on"
Month 6: Serious problems
  - Sunk cost says: "6 months invested, too late to switch"
  - Confirmation bias says: "Other teams had similar issues
    and pushed through successfully"
Month 9: Approach X fails
  - Sunk cost says: "We have 9 months invested, let us
    try one more thing"
  - Confirmation bias says: "It is almost working, we just
    need to fix this one issue"
Month 12: Project is canceled after 12 months
  - A rational analysis at month 4 might have saved 8 months

Engineering Antidotes

Pre-Mortems

A pre-mortem reverses confirmation bias by forcing the team to imagine failure and work backward to causes.

Process:
  1. Assume the project has failed spectacularly
  2. Each team member independently writes 3-5 reasons
     why it failed
  3. Share and discuss

This works because:
  - It gives permission to voice concerns (social cover)
  - It activates the brain's threat-detection system
  - It generates disconfirming evidence by design
  - It is harder to dismiss specific failure scenarios
    than vague concerns

Devil's Advocates

Assign someone to argue the opposing position.

Architecture review with devil's advocate:
  Proposer: "We should use event sourcing"
  Devil's advocate: "Argue against event sourcing"

  The DA's job:
  - Find the strongest arguments against the proposal
  - Present real-world cases where event sourcing failed
  - Identify hidden costs and complexities
  - Challenge every assumed benefit

  This is not adversarial. The DA is doing the team a
  service by fighting confirmation bias on their behalf.

Architecture Decision Records (ADRs)

ADRs fight both biases by requiring explicit documentation of alternatives considered and reasons for rejection.

ADR format that fights bias:

  ## Decision
  We will use PostgreSQL.

  ## Context
  We need a primary database for the user service.

  ## Options Considered
  1. PostgreSQL - relational, mature, team experience
  2. MongoDB - flexible schema, team has some experience
  3. DynamoDB - managed, scales automatically

  ## Arguments Against Our Choice
  - PostgreSQL requires manual scaling
  - Schema migrations are painful at scale
  - No built-in multi-region replication

  ## Why We Chose It Anyway
  - Team expertise reduces implementation risk
  - Our scale does not require auto-scaling yet
  - We accept migration pain in exchange for data integrity

  ## Conditions That Would Change This Decision
  - If we exceed 10TB of data
  - If we need sub-10ms global latency
  - If schema changes become more frequent than weekly

The "Arguments Against" and "Conditions That Would Change" sections are the key anti-bias features. They force the decision maker to engage with disconfirming evidence and define when the decision should be revisited.

Kill Criteria

Define in advance the conditions under which you will abandon a project. This fights sunk cost by making the stop decision pre-committed rather than reactive.

Kill criteria for a new service:
  - If latency exceeds 500ms after 4 weeks of optimization
  - If adoption is below 20% after 2 months
  - If maintenance cost exceeds 1 engineer-week per month

Kill criteria for a technology migration:
  - If we miss 2 consecutive milestone deadlines
  - If migration cost exceeds 150% of original estimate
  - If the new system fails 3 load tests

When a kill criterion is met, the default is to stop.
Continuing requires explicit justification.
This reverses the default: instead of "justify stopping,"
you must "justify continuing."

Reversibility Checks

Before committing to a major decision, explicitly evaluate reversibility.

Questions to ask:
  1. If this turns out to be wrong, how hard is it to undo?
  2. What would it cost to switch approaches in 3 months?
  3. Can we structure this as a reversible experiment instead
     of an irreversible commitment?

If the decision is easily reversible:
  Sunk cost is naturally limited. Decide quickly and iterate.

If the decision is hard to reverse:
  Invest more in fighting confirmation bias before deciding.
  Run pre-mortems, assign devil's advocates, write ADRs.

Common Pitfalls

  • Not recognizing sunk cost in the moment: The fallacy is invisible when you are inside it. "We have invested too much to stop" feels like a rational statement, not a bias. Train yourself to notice when past investment is driving future decisions.
  • Confusing sunk cost with learning: "We spent 6 months and learned a lot" is not sunk cost — learning has value. But "we spent 6 months so we must continue" is the fallacy. Distinguish between valuable lessons and throwing good money after bad.
  • Believing you are immune to confirmation bias: Everyone has confirmation bias. The question is not whether you have it but whether your processes compensate for it. Pre-mortems, ADRs, and devil's advocates exist because individual willpower is insufficient.
  • Over-correcting into indecisiveness: Fear of sunk cost can make you abandon projects too quickly. The antidote is kill criteria defined in advance — objective thresholds that trigger re-evaluation, not impulsive reversals.
  • Social reinforcement of both biases: Teams amplify these biases. Groupthink makes it harder to challenge a committed direction. Create psychological safety so people can say "this is not working" without fear.

Key Takeaways

  • Sunk cost fallacy: past investment should not determine future decisions. Evaluate future options based only on future costs and benefits.
  • Confirmation bias: you naturally seek evidence that confirms your beliefs and dismiss evidence that contradicts them. This is automatic and invisible.
  • Together, these biases create a dangerous feedback loop: sunk cost keeps you committed, confirmation bias prevents you from seeing problems.
  • Engineering antidotes: pre-mortems, devil's advocates, ADRs with explicit counter-arguments, and pre-defined kill criteria.
  • Kill criteria reverse the default: instead of justifying why to stop, you must justify why to continue.
  • No one is immune. Build processes and team norms that compensate for the biases you cannot eliminate from your thinking.