The Sunk "Code" Fallacy

In October of 2003, after investing more than £9.5 billion to build just twenty aircrafts, the French and British finally decided to retire the Concorde, one of the two supersonic jetliners to operate commercially. With a 9X budget overrun and no commercial viability, it’s hard to understand why intelligent and savvy leaders decided to keep this project going for more than 30 years. This behaviour is called the Sunk Cost Fallacy, also known as the “Concorde” Fallacy.

In the tech world, engineering teams can encounter the Sunk Cost Fallacy at:

The feature level (the feature that was supposed to take “just” a couple of sprints but is still nowhere near production), or,
The code level (legacy code that is maintained and patched, just because it took so long to write).

What is the Sunk Cost Fallacy

When we fall to the Sunk Cost Fallacy, we are most likely to continue an endeavour if we have already invested in it, minimising downsides and new information in the process. Psychologically speaking, there are three reasons why we would have such irrational behaviour.

The first reason is the commitment bias, where we stick to a previous decision despite new evidence showing it isn’t the best course of action. I also like to call it the “business plan” fallacy, under which entrepreneurs and investors keep executing a business plan just because it was agreed upon, while there is considerable evidence that the market isn’t responding. The second reason is the loss aversion bias, where we avoid being in a losing situation since losses feel much worse than gains. The third and last reason is the endowment effect, where we tend to attribute more value to something we own (or make) than something we buy.

How to avoid it

The main driver for the Sunk Cost Fallacy on the feature level is the use of estimates. Independently of your project methodology, there is a good chance that your developers estimate features before working on them. And estimates are super helpful. They help CTOs plan for headcount, help developers plan for sprints, and help product managers plan their roadmap.

But when it comes to new or innovative features, estimates can be too imprecise and often lead to significant overruns. Instead of estimating how long it will take to code a feature, you could estimate the maximum amount you’re willing to spend on this feature (based, for example, on projected benefits). This way, since you’ve already decided when the project will stop, you’re preventing both the commitment bias (as you’re “committed” to stop the project when you reach the maximum amount) and the loss aversion bias (as you’ve anticipated the loss).

You can even do it iteratively, making larger and larger bets. For example, imagine a SaaS startup selling only to small businesses. The Product team would like to introduce a new feature that could open the medium to a large company market. On the technical side, releasing this feature would require a significant reengineering of the back-end, the first since the company started, and switching to a programming language current developers don’t know so well. So lots, lots, lots of unknowns. Because it’s too dangerous to wait for the end of the project, you can schedule go/no go committees based on pre-defined milestones or metrics in advance. If the projects meet their KPIs, it’s allowed to continue until the following committee. If not, it’s killed right and there. Having a committee decide the fate of a project is also an excellent way to fight the endowment effect, other committee members balancing the project owners’ potential emotions.

On the code level, a good way to fight the Sunk Cost Fallacy is to write code that is easy to delete and regularly remove any old code that’s unnecessary. I’ve found that when it comes to deleting old code, old systems or anything that has become legacy, the more you do it, the less emotional it becomes. A good practice could be to organise regular “cleaning” sessions every quarter, where developers have to inspect old code to improve, replace or delete it.

In summary

💡

Falling to the Sunk Cost Fallacy is to continue an endeavour if we have already invested in it, minimising downsides and new information in the process.

💡

The Sunk Cost Fallacy can happen both at the feature level and the code level in software engineering teams.

To prevent the Sunk Cost Fallacy

💡

Establish in advance how much you’re willing to lose on an uncertain feature, schedule go/no committees in advance where multiple people will decide.

💡

Write code that is easy to delete and regularly remove any old code during “cleaning” sessions.