in General PHP, Opinion, Technology

The Fallacy of Sunk Cost

Last week, I began working on something that didn’t pan out. For whatever reason, I went down the wrong path, and ultimately abandoned the task I was working on. In discussing it with my boss, he mentioned to me that it was better to realize early on that something wouldn’t work than to trudge onward, insisting that it be finished due to the “sunk cost” of the time already spent.

This got me thinking about how often we consider the “sunk cost” in our decision-making process, especially when it comes to our software development.

The answer is, apparently quite often. In fact, considering the sunk cost and trying to mitigate losses is known as loss aversion. Human beings, in an attempt to be rational, often place a high value on work or money already expended; for example, if we’ve purchased an airline ticket for a vacation but lose our jobs two days before, we’re unlikely to cancel the trip and lose the money spent on the ticket, even knowing that going on the trip will incur additional expenses.

But in many cases, especially when in software development, there is a fallacy to sunk cost considerations. In the example I outlined in the beginning of this entry, continuing down the path I was on would have ultimately produced a working utility that would have been marginally useful. But it would have come at the expense of the rest of my work for that week.

This is not to say that developers should never consider the work already expended on a particular project or task; in fact, I’ve advised many times that rewriting an application is a fool’s errand in many cases. There is a fine line between choosing to continue down a particular path solely based on the fact that we’ve started down that path already, and choosing to make use of what we already have but selecting a different path to take.

It’s not an easy task to walk away from work that is in progress or is already finished. Learning to do so, and learning to identify the fallacy of sunk cost is important, though, because it helps free developers from guilt when throwing away work in progress, because they know it’s the wrong direction to go.

  1. we have a saying in dutch; “beter ten halve gekeerd, dan ten hele gedwaald”, meaning “better to turn back half-way than to get lost altogether”

  2. I think that “failing quickly” (as detailed by Scrum) is a key factor here. If you continue down the road of creating something you know is not the best solution, you are actively creating technical debt.

    It’s must better to raise the fact that something has gone wrong, as quickly as possible, to minimise the failed cost.

    It will be much cheaper to do it right, than to do it twice.

Comments are closed.