Welcome to Particletree!

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.

Sloppy Code

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.

Old Features

Right after releasing a prototype of Wufoo’s form building interface, we received some complaints from the Linux community that we were requiring a Flash 8 player to be installed (Macromedia! get on this!). We were already on a tight time frame, and Kevin had spent a lot of time learning and implementing the Flash 8 builder. One of the main arguments against switching was the large amount of time already invested, but we ultimately decided that you can’t live in the past. Ryan and Kevin probably spent three or four precious days completely rebuilding the interface in XHTML and JavaScript, but things turned out all right in the long run. In fact, we were actually able to make it even easier to use. If something in your application needs to be redone, don’t worry about how much time you’ve already invested, because that time is already gone. Instead, try to decide if reworking a feature is the best use of your time right now.

New Features

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.