If you’ve ever overeaten at an all-you-can-eat buffet just because you wanted to get what you paid for or nearly died of boredom at a terrible movie because you were compelled to “get your money’s” worth, then you’re familiar with the sunk cost fallacy. Basically, the sunk cost fallacy occurs when you make a decision based on the time and resources you’ve already committed and not on what would be the best way to spend your remaining time and energy. The sunk cost fallacy is usually applied to economics, but it can also pop up when you’re writing code or working on a new feature. Here are a few examples of sunk cost fallacy showing up in our workflow while programming.
Unless you’re the Yoda of programming, there’s going to be places where your code becomes unruly. This isn’t always the result of lack of effort (it’s nearly impossible to know exactly what every class or function will be responsible for six months down the road), but what often starts out as a “quick fix” usually ends up a labyrinth of code that has to be relearned each time you visit that problem area. The sunk cost fallacy happens when you continue to add to the inefficient code because you’ve already invested so much time into what’s there and because reworking the code would be a headache. The perspective you should take on the situation is weighing the time you’ll have to spend deciphering and adding to your spaghetti code in the future against how long it’ll take to rework it now.
Similar to old features, new features can also impair your judgment. One recent example of this was when I was working on a bug fix and saw the potential to not only fix the bug, but to also add some super cool new functionality. It was only after a day or so of programming the new feature that I asked Ryan and Kevin what they thought. They both told me it was a bad idea, but I argued that the feature should be finished since a day of programming was already invested. Looking back, it’s a good thing that I was overruled, and completing the unfinished feature would not have been the best use of my time. Users don’t care how much time was spent on a feature they don’t really want.