The Sunk Cost Fallacy

The Sunk Cost Fallacy

I gazed out of the window. The birds were chirping and the weather was sunny. People were trying to get their first dose of coffee from the nearby coffee shop. Some tables were occupied by people who were hustling and busy getting work done on their laptops while some tables were occupied by people trying to relax and take pleasure from every sip of their coffee. I smirked while observing them, I felt their collective range of emotions in past seven months. One day, I was the guy trying to make every minute count while another day trying to take in the essence of the surroundings.

T - Life is beautiful

I was already late for the meeting. I rushed through the corridor to reach the meeting hall to find my superior waiting for me. I had to take over a feature project from him and had a knowledge transfer session with him. The project included an end to end feature which means touching and adding lots of code. I analysed the design and cross-checked the expectations with the team and stakeholders, everything seemed fine. Exciting times were ahead!

A meeting was called upon with members assigned to this feature development project. We had to decide if we want to make our feature scalable and flexible for further iterations to come. Pros and cons were discussed for every point made and it was decided we would spend more time to make the feature scalable and flexible so that milestones concerning further feature iterations would be achieved in no time. Implementation seemed fairly simple and major points made in the meeting were duly noted.

T + 2 - Fire

I was looking at my coffee mug. The coffee looked extra dark today. My mind was boggling with one hypothesis and I was trying to convince myself that it’s a lie. The coffee was not dark. My thoughts were.

Z: “Hey! You okay?”

My colleague was standing beside me without his laptop. He was seemingly not happy.

Z: “I think this is a bug, it should not work like this.”

Me: “It is correct, It’s part of the feature.”

Z: “We did not discuss this in the design meeting.”

Me: “We should have discussed this, I remember it being documented.”

I checked the documentation and this part of the feature was not to be found anywhere. My two worst fears had come true.

• I didn’t document the meeting notes of my KT and this part of the feature somehow skipped being documented in design notes.

• Every team member working on this feature has a different understanding of the feature.

T + 4 - Let it go

I was walking by the river. The sky was looking beautiful with clouds of different shapes chatting with each other and the air passing through the meadow beneath seemed like it was whispering something to me. I closed my eyes focusing on its voice.

“Let it go”.

I opened my eyes. The world was on fire. Knowledge transfer became more difficult. Pair programming was no longer sitting beside your colleagues and watching them code but it was highly dependent on your house’ internet connectivity.

The progress of the feature seemed like a hallucination. In pursuit of scalability and adaptability, the design had become complicated, to begin with. We had already crossed the deadlines. There was no escape from this “black hole”.

I fetched myself a cup of coffee, sat on my desk and opened my laptop. My dream was still lingering in my mind and I was not sure what the dream meant. I looked at the code. A thought came to me.

“Why not rewrite the implementation of this feature with a much simpler and leaner design !?.”

But another thought hit me, which threw me into a dilemma.

“We have invested so much time working on this for a couple of months. Even though the design is complicated, we should continue following it since we are already midway. It will anyway fulfil the requirement even if it takes longer than undoing current implementation and rewriting a new one. “

After some thought process, I came to a conclusion,

“The initial “complicated” design consisted of so many assumptions out of which some were revealed to be not incorrect. We had to anyway rethink those parts of design again. This initial design also aimed to be inclusive of future milestones which we were never certain that they would get approved by the management. It makes sense to rewrite this feature with narrowed down design to cover just the customer requirements and not think much of the future and milestones.”

I discussed this with the team and we chose to rewrite this feature code with a simple design.

T + 7 - The end

It was a pleasant morning. I had 10 minutes left for the release meeting. A quote from my favourite game, Skyrim struck me.

“I fight so that all the fighting I’ve already done hasn’t been for nothing. I fight… because I must.”

The king wanted to keep fighting even after he lost half of his men, just so that their sacrifices don’t go to waste.

Economists coined a term for this, “sunk cost fallacy”.

The Decision Lab defined it as

“The Sunk Cost Fallacy describes our tendency to follow through on an endeavor if we have already invested time, effort or money into it, whether or not the current costs outweigh the benefits.”

There are various ways to avoid this, the easiest being to let go of your fear and attachment to failing projects and make room for better brighter things. And who knows, this might actually pave out a way to further successful and profitable projects.

It was time for my meeting. My manager was about to announce the completion of this feature which we devoted several months on.

“So finally we managed to complete this feature this release”.

We sighed with relief. We had just finished the most complicated and long-lasting feature project our team had ever faced. One of my team members even took a long holiday once we were finished.

I quickly glanced through my diary. It had scribbles of the lessons I had learnt. They were written as follows:

• Use sunk cost fallacy whenever applicable.

• Don’t assume things. Take note of “known unknowns” and find answers to them before making major decisions.

• Document everything.

• Follow the KISS ((K)eep (I)t (S)imple (S)tupid) methodology wherever possible.

• Teamwork is necessary to revive failing projects. It is the foundation on which successful projects stand upon.

I closed my diary. “It was a long adventure”, I thought. Now it’s time for another one.

“Blessed are the curious as they shall have adventures” – Lovelle Drachman

Disclaimer: The sole aim of the article is to emphasize sunk cost fallacy and not to criticise anyone’s decision making or code.