Development & The Sunk-Cost Fallacy

What Building Software & Riding a Motorcycle Have in Common

In a way, building software is kinda similar to riding a motorcycle. Bikers are called organ donors for a reason. Because if they ride long enough, the will wreck.

It’s not a question of "if", but a question of "when".

Every successful developer has, or will, fail at some point. Probably multiple times if we are being honest. To borrow a line from Jax Teller on Son’s of Anarchy, “That’s the price you pay for not being stuck in a cage [car].”

What separates the good developer from the bad one is not the failure, its what you do with it. Did you learn from it? Good! Now don’t fail the same way next time.

While we are on the subject of failure, let’s talk about the sunk-cost fallacy and the problem it presents. Sunk cost is an expense that's already been paid for something and cannot be recovered. We tend to fight harder to avoid loss than we do to aquire a gain (aka: loss aversion). This is the reason you still have a closet full of clothes that haven't fit properly for a long time. Every time you think about getting rid of them, you tell yourself that maybe, just maybe, you’ll be able to wear them again one day. It’s the reason that I have an old Volkswagen that hasn't run in a long time but I can't seem to get rid of it. I've spent so much time working on it that, if I let it go now, I'll feel like all that time was wasted.

What sunk cost does in your developement is it tricks you into thinking that you can throw more code, more time, more resources at a problem and eventually it will work out. Don't get me wrong, sometimes all you need is a little grit to see it through. But if the issue is big enough or if the problem you're trying to solve isn't even the problem that needs to be solved, then it might be better to just burn everything to the ground and start over.

Successful developers learn to recognize the signs that it's time to kill a product or feature. They learn from it. And then they do it again, but with a little more wisdom.

It's understandable to have a bias for something you've spent tons of time working on and thinking about. But don't be fooled into thinking that it's your "baby." It's not. It's code. It comes in goes. The code isn't important, what's important is solving the problem.