Andrew’s Coding Corner- Beware the Sunk Cost Fallacy

It’s a familiar tale. A project becomes stuck in the mud. Perhaps the project was poorly designed, or perhaps the team was overmatched, or perhaps a series of unfortunate events took place rendering the best of everything else moot. Estimates start getting missed badly, and the teams stress levels skyrocket. It turns out that the way they were heading just makes no sense, and won’t ever make sense. All in all, everything is leading to a failure. Nevertheless, everybody just keeps going down the same path. Perhaps they do it reluctantly, knowing it will fail, but not daring to venture another path. Perhaps they delude themselves into thinking everything is fine. Whatever the case, the water keeps rising until the whole thing sinks.

Why does this happen so often? Is it ego run amok, a strong urge by most people to refuse to admit mistakes? Or is it the cost of doing business, the expected inertia of a collaborative project? While those factors certainly play a role in the situation, most often it’s an example of the “sunk cost fallacy”. The idea is that since we’ve already devoted so much time and money to the current situation, we better just power through no matter what. It’s a very understandable, and human, response.

However, it is quite often a terrible way to approach a problem. Unless you have a time machine, that effort expended is not coming back. Unless you get really lucky, any money you spent to reach this unenviable position is also gone. At this point, all that matters is the amount of effort and money that will be expended in the future. Continuing on your not-so-merry way isn’t likely to salvage the project. In fact, it’s more likely to dig your hole even deeper.

So what do you do? Take a step back, get a good grasp on what you are trying to accomplish, and find a different path. Whether a developer caught in a quagmire of a module/class/method or a manager and team trapped in Development Hell, take the night off. Go see a movie, watch a ball game, or just veg out for a while. Get a good meal and a night’s sleep, and attack it again the next day. It’s amazing what path you can find out of the nether-regions when you look at it with fresh eyes.

And yes, sometimes there is no fresh solution, no new path that would be possible without being prohibitively expensive. These kind of Kobayashi Maru situations do happen, and often you have to just pick the least bad option. If you find yourself in this scenario, there isn’t a complete lack of hope. See if you can lower the breadth of your new vision, and maybe at the least lessen the damage a complete adherence to the status quo would bring. If that isn’t even an option, then take a deep breath, hold your head up, and take what’s coming with as much grace as you can muster.

Ideally, the best way to handle this is to never reach a “point of no return”. Learn to recognize deteriorating situations before they get too bad, and make sure you take care of them before moving on. If you are trying to get your code done and just keep patching holes (rather than fixing the underlying problem), perhaps its time to ask for help. This doesn’t mean constantly flip back and forth between ideas, or dither incessantly about where things are going. It’s a fine line between being committed to a valid course of action and stubbornly pushing through an untenable situation.

Share
Andrew

Andrew

I've been a programmer for almost 15 years, back in the rough early days of PHP 3. Am well versed in the world of PHP and MySQL. I have a deep appreciation of ZF2 and Doctrine. The thought of all the spaghetti code I've dug through (and written) keeps me up at night sometimes. My profile picture is not of me.
Andrew

Leave a Comment

Your email address will not be published.