First published January 2010. This one holds up, I think. Here is my first lesson from poker. I take that back. My first lesson from poker is when two strangers ask if they can join the game, lose a little all night, then offer to cut the cards for $100 as the game is breaking up, count the deck before and then after they turn up the ace.
One of the best. I continue to fall prey to the Suck Cost Fallacy after a long series of changes. Sometimes I can grit my teeth and revert. Often it seems that I cannot, even though I *know* it's going to go better next time. What really saves me, often, is small steps with a Green between each step.
Great stuff: the classics as well as the new ones! Thanks!
This is beautifully written Kent. This kind of insight can be life changing.
It reminds me of an idea expressed by Adam Grant in the book “Think Again”. In it he talks about The Joy of Being Wrong - based on conversation with Danny Kahneman. Kahneman (who studied biases for much his career) said he enjoyed being wrong about something, and learning that he was wrong, because from that realization he was “now less wrong than before”.
This just happened to me this week. Despite decades of experience that should have made me know better, while I was refactoring a test to clean it up, I stupidly started changing the code at the same time (not my test, someone else's who was unfamiliar with the idioms of the particular test framework).
Because I know better, right, and can just fix this up all at once? (there were mitigating factors in I could share my defense, but those excuses don't matter)
Of course I quickly ended up in a completely confused and broken state.
I stopped, threw in the towel (and threw away my changes), and just created a follow-up issue to clean up the spec later. Because it was fine the way it was, had decent logic coverage and did the job.
I sometimes have the reverse problem. Due to the awareness of the fallacy, I tend to throw things away. This caused problems before, therefore, I do think that there are times where knowing the magnitude of energy that have been invested in the past could led to better decision.
Recent example: A team has adopted framework A two months ago. I joined 1 month later, and we realised that it's a mistake, I was about to throw it away and adopt framework B, "Sunk Cost Fallacy", I thought.
I looked at the energy invested in the past. Given that the team is a complex system, the parts have now changed even by adopting framework A. Noticing the change, the idea of framework C emerged, and made more sense.
> What I should do now should not be influenced by the magnitude of time I already have invested.
I can't articulate it well, but with this example, I think it's important to be aware of the fallacy, but the sunk cost shouldn't be entirely dismissed as it may have impacted the system in other ways.
One of the best. I continue to fall prey to the Suck Cost Fallacy after a long series of changes. Sometimes I can grit my teeth and revert. Often it seems that I cannot, even though I *know* it's going to go better next time. What really saves me, often, is small steps with a Green between each step.
Great stuff: the classics as well as the new ones! Thanks!
Ron, you wrote "Suck Cost Fallacy." I like that variant term, just trying to figure out a situation to use it! Cheers!
What saves me is to commit after each green. Not being able to revert makes me fall prey to the Suck Cost Fallacy more.
This is beautifully written Kent. This kind of insight can be life changing.
It reminds me of an idea expressed by Adam Grant in the book “Think Again”. In it he talks about The Joy of Being Wrong - based on conversation with Danny Kahneman. Kahneman (who studied biases for much his career) said he enjoyed being wrong about something, and learning that he was wrong, because from that realization he was “now less wrong than before”.
First lesson in investing: as soon as you invest it's not your money anymore - it's the market's.
Very interesting. I'd not thought of the Sunk Cost Fallacy in that context. Good way of looking at it.
This just happened to me this week. Despite decades of experience that should have made me know better, while I was refactoring a test to clean it up, I stupidly started changing the code at the same time (not my test, someone else's who was unfamiliar with the idioms of the particular test framework).
Because I know better, right, and can just fix this up all at once? (there were mitigating factors in I could share my defense, but those excuses don't matter)
Of course I quickly ended up in a completely confused and broken state.
I stopped, threw in the towel (and threw away my changes), and just created a follow-up issue to clean up the spec later. Because it was fine the way it was, had decent logic coverage and did the job.
Ever smaller mistakes. That's the best we can do.
I sometimes have the reverse problem. Due to the awareness of the fallacy, I tend to throw things away. This caused problems before, therefore, I do think that there are times where knowing the magnitude of energy that have been invested in the past could led to better decision.
Recent example: A team has adopted framework A two months ago. I joined 1 month later, and we realised that it's a mistake, I was about to throw it away and adopt framework B, "Sunk Cost Fallacy", I thought.
I looked at the energy invested in the past. Given that the team is a complex system, the parts have now changed even by adopting framework A. Noticing the change, the idea of framework C emerged, and made more sense.
> What I should do now should not be influenced by the magnitude of time I already have invested.
I can't articulate it well, but with this example, I think it's important to be aware of the fallacy, but the sunk cost shouldn't be entirely dismissed as it may have impacted the system in other ways.