The Sunken Costs Fallacy And How To Avoid It.
We’ve all been there. 3 weeks into a single task and despite your best efforts, the way you’ve decided to tackle it is becoming more and more cumbersome. If you knew what you know now at the start of the task, you’d do this very differently — but you’re 3 weeks in and need to deliver something, right?
Here’s an example.
A couple of months ago, I wanted to create a beautiful, horizontally-scrollable, multi-selectable, totally-awesome answers panel for a new feature on a website. Being the lazy software engineer I am, I decided that someone else must have already done this, so I headed over to the npm registry to see what I could use.
Sure enough, there were many packages that promised to fulfil my every need and more, which could be implemented easily! What luck!
However, a few hours into the implementation I noticed it was a little slower than I would have liked — but maybe that was something that could be improved down the line. Next, there were some issues around the styling which required a bit of a workaround. Further down the line, there were more issues that required yet more workarounds.
Eventually, after a week or two of solving one problem at a time with this 3rd party component, the feature was ready. Success right? It was probably still quicker than writing it from scratch. Maybe.
Well — not really a success. The code was… not unreadable, but if I came back to it in a year it would take me a while to figure out why it was written this way. There were definitely some bad smells lingering around the code, manipulating the inner workings of the component, etc. The feature itself was still slow. It didn’t do everything I wanted it to.
Overall, it was pretty sub-par.
So, a short while later we decided to reimplement it from scratch. And guess what — it works like a dream, the code is clear and concise, it has all the bells and whistles, and it didn’t even take that long. It’s now something I can be proud of.
So what’s the moral of the story? Don’t use open-source software? Do it all yourself? Be a 10x rockstar developer hero and drink 18 cups of coffee an hour.
Not at all. Apart from the coffee. ☕️
Sure, in this case, it seems like creating our own implementation was the most efficient way — but maybe there is a great tool that we weren’t aware of.
So how do we avoid the sunken costs fallacy? Clearly, it would have been more efficient to do it ourselves from the start, and I had that thought many times during the development process — but I was so far in that I didn’t want to ditch all of my hard work in favour of starting from scratch!
So no, the answer is not just “do it yourself always”. It’s a little more complex than that, unfortunately.
I think the issue is that we’re not asking the correct question. It’s not “How can I avoid the sunken costs fallacy?” (despite what the title of this post would have you believe), it’s “At what point in the development process should I switch it up and try a different approach?”
Hint: It’s not “Drop everything at the first hurdle”
I think the answer is only going to be found on a case-by-case basis, but there are some guidelines you can follow to get an idea of when might be a good time to rethink your approach.
Every time you hit an issue, which could be:
- You’re not getting the right value from what you’re making
- Your approach does not enable you to add all of the features you want
- Your code is looking ✨ iffy ✨
- Something else
Make a note of the issue, that’ll help when you’re coming back to think about this in the future, and as you do this, think:
- Do I know more than I did at the start? And would that knowledge guide me to implement this in a different way from the start?
- If I continue, will the final implementation be good enough?
(N.B. Good enough and complete is better than perfect but incomplete) - Can I foresee any further issues with this approach?
- If I try a different way, am I likely to hit similar issues?
It’s worth pointing out that you don’t have to know any of the answers to those questions in order to justify trying something different. And you don’t have to know if different will be better, but it might be worth allocating some time to try something out, and if you hit blockers then come back to what you were already doing.
That sums up my thoughts on the Sunken Costs Fallacy and how we might be able to reduce its impact on what we produce, and when we deliver it. This post is targeted at a software engineering example, but I’m certain it applies in other areas of business too.
Do you have anything you do to avoid the Sunken Costs Fallacy? Please share in the comments below!
