The Sunk Cost Fallacy... and Your Code
What is a sunk cost? In its strict definition, a sunk cost is one that cannot be recovered. You've spent something and you're not getting it back. Having a sunk cost is a common occurrence in life, like that time your car broke down and you spent money on five different mechanics trying to make it right again and bring it back from the dead, but in the end, and to no avail, the car never does come back, and your money and your time are gone forever, and you sell that piece of junk car for a fraction of the value it once had. That is a sunk cost.
What is the sunk cost fallacy? The delusion that, because you've already invested so much on fixing that car, you must keep spending. It's the misplaced hope that you didn't just waste a month's salary and hours upon hours of your precious time on a dead end. It's the hope that everything will work out if you keep at it, and your suffering is not in vain. It's perseverance taken to the ridiculous extreme, and it's not rational. It's an emotional middle finger to increasingly strenuous circumstances. It's not wanting to say 'I give up' when everything else points to impossibility.
So what about my code? You may be asking. Well, it turns out us coders are not exempt from this fallacy. In fact, in my experience, it's too common. Say you've been tasked with implementing a new functionality to the application you're building. It looks great on paper, and if you get it right, the application will be so much more user friendly, and everyone will be happy and you'll be congratulated and when you're done, you'll smile at a job well done. And guess what? You find that there's a library that already does 95% of the functionality you're looking for. Why reinvent the wheel, right? So you download it and begin work on the remaining 5%. By your estimates it'll take you no more than a week, after all, 95% of the work is done already.
This is where troubles begin. The first day goes by and it all seems well, and when asked about progress you say you're ahead of schedule. The second day passes and you notice interfacing with that third-party library is not as easy as it seemed, but it's okay, you still have three days left. By the end of the fourth day, and having completed 99% of the desired functionality, you are sweating tears and blood. You've been dodging questions on progress and worst of all your code now looks like a bad re-imagining of Mary Shelley's 'Frankenstein'.
The code is not re-usable, maintaining it would be a nightmare for future you, and building upon it would be next to impossible. The end seems to elude you, like a finish line across an abyss just large enough to be unreachable, and now you're sitting there, with your legs dangling in the void, thinking there must be a way. It's just so close, and you've worked on it for 40 hours, and your boss is expecting it tomorrow, and by god it's so close!
So what do you do? Herein lies the dilemma, and the crux of the sunk cost fallacy. Do you continue working, hoping that maybe, if you work for five more days, you will attain that last 1%? Knowing full well that the code is now a mess? Knowing that it's not the best solution? Or do you admit defeat and talk to your boss and accept you made a wrong decision with the third-party library and endure the sighs of disappointment?
Admit defeat. This is the correct answer.
We are all, in the end, and most unfortunately, human. And we err. Yes, you made a mistake. Yes, you've just wasted your time and maybe company money. No, you did not deliver on time. The release will have to be delayed, but it is the correct choice. Why? Because it is the only choice. To continue down the first attractive, yet wrong path, would have resulted in a greater waste of time and money. Own up to it and try a new solution.
What is the moral of this story? Learn to identify that sense of impossibility approaching, and when you look into the uncrossable abyss, give up, go back, and try a different approach.