The sunk cost fallacy: is your code worth the effort?
Some people say that the definition of madness is doing the same thing over and over, expecting different results. When it comes to the investment of resources, however, slugging away at the same plan – even when it isn’t working – is a common phenomenon.
It’s known as the sunk cost fallacy. Hour upon hour, more and more resources are sunk trying to make a dead end into something useful. Sometimes, you need to know when to walk away and try something else; when to cut your losses before it’s too late.
So, how do you tell if you’ve fallen foul of the sunk cost fallacy in programming? Is your code worth the effort?
What is the sunk cost fallacy?
Sunk costs are the invested resources – time, money and effort – that you cannot recover. The sunk cost fallacy is a problem that these non-recoverable investments can cause.
For example, you’ve invested time and resource into creating a new feature for your SaaS product. But the code is getting messy, and the functionality you were after is still out of reach. Now, you find yourself at a crossroads. Do you turn away and try a new path to your goal, giving up all the time and money you’ve spent on your current path?
When an investment doesn’t deliver the expected outcome, it’s common to want to invest more in making it work – you don’t want to lose out on the effort you’ve already sunk. You pour more resource into it, desperately hoping you’ll make something that can’t work produce results. It seems so close. You can’t have wasted all that resource on a dead end, right?
Unfortunately, throwing more resources at a problem won’t fix it – and the longer you fall foul of the sunk cost fallacy, the harder it gets to escape. Tenacity down the wrong path won’t bring your end goal any closer.
A good chance?
That isn’t to say that setbacks always mean you’re heading down the wrong path. For example, no one would suggest giving up on a new business at the first bump, or a marriage at the first argument. So, don’t give up on your code if you can clearly see that it will get you to your end goal.
The sunk cost fallacy only applies when you’ve already given the investment the chance to work it should have needed. If your venture is still failing after being given that good chance, it’s time to walk away and try something else. Don’t keep going, blindly hoping you can make the solution work, just because you’ve spent resources on giving the idea a chance.
Preventing major losses: is your code worth it?
- Clear future goals
One reason for the sunk cost fallacy comes from a shift in focus. Instead of focusing solely on the end goal of your SaaS product or the feature you’re working on, focus shifts to the past investment instead. When you find yourself at the sunk cost fallacy crossroads, make sure that the future outcome is the focus of your coding – not the investments you’ve already made.
- Multiple decision makers
A good way to avoid falling foul of the sunk cost fallacy is to make sure that more than one person decides whether to continue with a project. Sometimes, people are too proud to admit they were wrong, or too worried about their job to risk admitting an error.
It’s easier to look at a project with clear eyes when you aren’t the one that made the initial investment. Someone who isn’t responsible for the sunk costs is more likely to be able to see when a feature isn’t going to work.
- Analyse other options available
Is there a more suitable way to accomplish the goal? When hit by the sunk cost fallacy, code can get more complicated and messy than anticipated. This means that even if you spent more to make it work, your code may not be maintainable. So, be open to other approaches. There could be a more efficient way to reach your end goal.
Runaway train
The sunk cost fallacy is like a runaway train. Once it starts, it builds up speed, and it gets increasingly difficult to stop. The more investment you put into a failing feature, the harder it is to cut your losses and let it go.
So, remember that past investments don’t have to dictate future decisions. Don’t get caught by the sunk cost fallacy. If your code is taking longer than it should, or you aren’t making any progress towards your end goal, it’s time to evaluate whether you need to hit the brakes and try again elsewhere.
Useful links
Is your software idea worth developing?
The top 3 benefits of building an MVP: why you need to begin with a minimum viable product
