Visions and Mirages: The Sunk Cost Dilemma

I think the objections raised by (e.g.) Unknowns, Lumifer and shminux are basically correct but they aren't (I think) phrased so that they exactly match the scenario OrphanWilde is proposing. Let me try to reduce the impedance mismatch a little.

OrphanWilde's scenario -- where your schedule keeps slipping but even with perfectly rational updating continuing always looks like a win -- is possible. But: it's really weird and I don't think it actually occurs in real life; that is, in reality, the scenarios that most resemble OrphanWilde's are ones in which the updating isn't perfectly rational and you would do well to cut your losses and reflect on your cognitive errors.

What would a real OrphanWilde scenario look like? Something like this.

• You begin a project to (let's say) build a bridge. You think it should be done in six months.
• After four months of work, it's clear that you underestimated and it's now going to take longer. Your new estimate is another six months.
• After another four months, it's now looking like it will take only three months more -- so you're still going to be late, but not very. You no longer trust your prediction abilities, though (you were wrong the last two times), so you adjust your estimate: another six months.
• After another four months, you've slipped further. Your error bars are getting large now, but you get a message from God telling you it'll definitely be done in another six months.
• After another four months, you've lost your faith and now there's probably nothing that could (rationally) convince you to be confident of completion in 6 months. But now you get information indicating that completing the bridge is more valuable than you'd thought. So even though it's likely to be 9 months now, it's still worth it because extra traffic from the new stadium being built on the other side makes the bridge more important.
• After another six months, you're wearily conceding that you've got very little idea how long the bridge is going to take to complete. Maybe a year? But now they're planning a whole new town on the other side of the bridge and you really need it.
• After another nine months, it seems like it might be better just to tell the townspeople to swim if they want to get across. But now you're receiving credible terrorist threats saying that if you cancel the bridge project the Bad Guys are going to blow up half the city. Better carry on, I guess...

What we need here is constant escalation of evidence for timely completion (despite the contrary evidence of the slippage so far) and/or of expected value of completing the project even if it's really late -- perhaps, after enough slippage, this needs to be escalating evidence of the value of pursuing the project even if it's never finished. One can keep that up for a while, but you can see how the escalation had to get more and more extreme.

OrphanWilde, do you envisage any scenario in which a project keeps (rationally) looking worthwhile despite lots of repeated slippages without this sort of drastic escalation? If so, how? If not, isn't this going to be rare enough that we can safely ignore it in favour of the much commoner scenarios where the project keeps looking worthwhile because we're not looking at it rationally?

But at each step, you discover another step you didn't originally anticipate

That is the core of your problem. Since it's happening repeatedly, you should stop assuming that you know the distance to completion and assign a probability distribution to the number of step (or time) needed to get the project done, likely with a long right tail.

If you constantly encounter the unexpected, you should acknowledge that your expectations are faulty and start to expect the unexpected.

I don't understand the point of this.

I mean, I get that OrphanWilde is feeling very smug at having been able to "mug" some other people in the discussion here, and that this mugging is meant to be analogous both to the situation (deliberately incoherently) described in the article and to things that happen in real life.

But ... so what? Are we meant to be startled by the revelation that sometimes people exploit other people? Hardly.

And what seems to be one of the points you say you're trying to make -- that when this happens we are liable to assume it's our own fault rather than the other person's malice -- seems to me to be very ill supported by anything that's happened here. (1) I don't see other people assuming that the confusion here is their own fault, I see them trying to be tactful about the fact that it's yours. (2) I would expect posters here to be more willing to give benefit of the doubt than, e.g., in a business situation where they and the other party are literally competing for money. (3) You say "Here, I mugged you for a few seconds or maybe minutes [...] in real life, that would be hours, weeks, months" -- but I see no reason to expect people to be orders of magnitude slower in "real life" than here.

Further, you didn't in fact exploit anyone because (unless you're really malicious and actually enjoy seeing people waste time to no purpose, in which case fuck you) you didn't gain anything. You (at most) just wasted some people's time. Congratulations, but it's not like that's terribly hard to do. And, perhaps, you just made a bunch of people that little bit less inclined to be helpful and understanding to some confused-seeming guy on Less Wrong in the future.

I'm downvoting your post here and your replies in the comments, and would encourage other readers to do likewise. Making Less Wrong incrementally less useful in order to be able to preen about how you exploited people is not behaviour I wish to encourage here, and I see no actual insight (either overtly expressed or implicit) that counterbalances your act of defection.

[EDITED to add: OH HA HA I JUST MUGGED YOU AREN'T I CLEVER]

Also, in practice this only happens when someone is procrastinating and the supposedly additional steps are just ways of avoiding the more difficult steps, so a reasonable estimate of the remaining time to completion is that person is simply not going to complete the task, ever.

This is the Planning Fallacy, for which the remedy is the Outside View: ask how similar projects have turned out in the past. That will likely be more accurate than imagining how this particular project will go.

I have heard (but do not have personal experience) of a rule of thumb for software developers when quoting a number of days work for a project. Imagine the longest it could possibly take, then multiply by three.

But perhaps you have not taken an outside view at the start, and got into a project that is multiplying like a hydra? Then take the outside view now, avoid the Sunk Cost fallacy, and ask, is the difference in payoff from completing vs. abandoning the project worth the difference in costs, now realistically estimated, that will be incurred from here on?

This was an interesting article. I've been involved in software consulting in the past, and this sort of mugging does sometimes occur in fixed-price projects. I think that there are several take-aways from this:

• fixed-price projects are a lot higher risk (to the service provider) than are time and materials projects. This is true even if the service-provider is good at estimation and applies appropriate buffer in the schedule/pricing.

• fixed-price projects require a skilled project manager who can recognize and manage scope creep (intentional and otherwise)

• fixed-price projects require diligence up-front in crafting an unambiguous statement of work or contract

• one-person or small project teams without a dedicated project manager should think twice before accepting fixed-price assignments

The last bullet is worth emphasizing; some technical people, wishing to stay focused on the work, will acquiesce to scope creep (particularly if introduced incrementally) to avoid getting involved in time-consuming and potentially adversarial discussions with the client. This can make manager-less teams particularly vulnerable to this type of mugging. An experienced project manager can often mitigate this danger.

But at each step, you discover another step you didn't originally anticipate, and had no priors for anticipating.

if this is the case, your issue is unrelated to sunk cost, it is the Planning Fallacy. You've failed to perform the proper risk analysis and mitigation. The excuse "had no priors for anticipating" is only valid for black swan events, but not for your run-of-the-mill problems every project has.

So, when faced with the situation you describe, one should stop barking up the wrong tree and and do a pre-mortem.

Hopefully, I'm not just feeding the troll, but: just what exactly do you think "the sunk cost fallacy" is? Because it appears to me that you believe that it refers to the practice of adding expenses already paid to future expected expenses in a cost-benefit analysis, when in fact in refers the opposite, of subtracting expenses already paid from future expected expenses.

It seems that you are expecting a situation somewhat like this:

Day 1: I expect to be done in 5 days. Day 2: I expect to be done in 5 days. Day 10: I expect to be done in 7 days. Day 20: I expect to be done in 4 days. Day 30: I expect to be done in 5 days.

Basically, this cannot happen if I am updating rationally. You say, "Worse, each additional step is novel; the additional five steps you discovered after completing step 6 didn't add anything to predict the additional twelve steps you added after completing step 19." But in fact, it does add something: namely that this task that I am trying to accomplish is very long and unpredictable, and the more such steps are added, the longer and more unpredictable I should assume it to be, even in the remaining portion of the task. So by day 30, I should be expecting about another month, not another 5 days. And if I do this, at some point it will become clear that it is not worth finishing the task, at least assuming that it is not simply the process itself that is worth doing.