The Sunk Cost Fallacy in Software Development

In my recent story of Zen and the Art of Gambling, a tradesman goes to the casino and keeps betting until he eventually wins.

Whereas we can easily spot the cognitive fallacy in this particular story, in software development, the same fallacy often remains unnoticed.

I remember when we were building this new feature in a planning system for a services business. It allowed customer service representatives to issue refunds to customers as a way to resolve complaints.

Although the feature seemed simple enough, it interacted in interesting ways with functions concerning discounts, taxes, and payment collection. So we estimated a substantial amount of time for its realisation.

It still wasn’t enough. We ran into numerous problems, and for every problem we solved, another one seemed to pop up. The intricate system architecture, which provided support for multiple countries, tax systems, languages, currencies, and third party APIs, wasn’t making things easier.

Once it became clear that we would go over budget, neither the client nor us stepped on the breaks. We just kept pushing forward because we didn’t want to write off our work.

The better approach would have been the stop-loss order, as explained in this video. With a stop-loss order, senior management, product management and the development team sit together before work begins, and decide upon betting a certain amount of development time to build something with a large (and quantified!) upside potential. If the feature can’t be completed within that time, development is halted, so that the loss stays within predefined limits.

Stop-loss orders are a rational approach to manage risk, ensuring that risks and returns are understood before resources are committed. Adopting this type of economic thinking is crucial. Without it, senior management will view software as a cost, rather than an income-generating asset. As product managers, we can’t let that happen. Our responsibility is to be part of the solution, not the problem.

As I once heard a CFO say: “There are two lines at my office. A long line of people with ideas that cost money. And a short line of people with ideas that make money.”