# Sunk Costs Fallacy Fallacy

I have a problem with never finishing things that I want to work on. I get enthusiastic about them for a while, but then find something else to work on. This problem seems to be powered partially by my sunk costs fallacy hooks.

When faced with the choice of finishing my current project or starting this shiny new project, my sunk costs hook activates and says "evaluate future expected utility and ignore sunk costs". The new project looks very shiny compared to the old project, enough that it looks like a better thing to work on than the rest of the current project. The trouble is that this always seems to be the case. It seems weird that the awesomeness of my project ideas would have exponential growth over time, so there must be something else here.

The "evaluate future expected utility and ignore sunk costs" heuristic works well for life-planning where people get status quo bias and financial-utility things where utility is easy to calculate consistently. In fact it seems like generally good decision theory, except that I'm running on corrupted hardware. My corrupted hardware seems to decay the perceived value of a project over the time that I know of it, or inflate it when it seems new and exciting, which of course throws off the sunk costs hook's assumption that I can evaluate utility \*consistently\*.

So my sunk costs hook has a bad assumption. I don't want to go modifying the hook in a way that would break its applicability to economic and life-planning situations or its theoretical correctness, so I'll just add "this assumes consistent utility function". This of course doesn't actually help me on the project planning case, I need to put a hook on evaluating the utility of a project that makes the utility function consistent.

Some things that might de-skew my evaluation of exciting new projects:

*   If the project is new, it probably looks shinier than it is. I should wait a while or try to correct for this before evaluating.
*   I should take into account my record of defecting halfway thru a project to discount the utility of the new project.
*   The latter half of a project is relatively untouched territory, full of valuable new experiences. I will have to work thru the first half of the new project to get to this, but I am already at the threshold on the current project.
*   Maybe there's more?

So I'll see how this works out.

I think this situation is probably not unique. Many of our debiasing hooks are formulated to combat specific biases but might catch situations outside their domain. In this example, the sunk costs bias is a real thing, but the hook to catch it was also catching a situation where sunk costs was not the primary bias, and actually ended up contributing to bias.

It might be valuable to think about what other situations a hook might catch, and modify it to not screw things up before we install it. Also, other biases may act in the opposite direction, and only hooking one of them might make things worse.

Anyways, that's my thoughts on a specific bit of debiasing. Maybe you all have some other examples of this sort of thing, and maybe this will be useful for people who have the same problem.