Sunk Costs in Software

Ignoring the effect of sunk costs in decision making leads to more expensive projects, longer development times, and lower quality. Here I'll try to help all of us stay on the lookout.

What are sunk costs?

Sunk costs are effectively "whatever you've spent/invested so far." This is time or money spent on something that you can't get back (you certainly can't take back time!) These stand in constrast to prospective costs, which are future ones that you may avoid or influence by taking action.

In principle, sunk costs these shouldn't factor in forward-looking plans, because how you get into a situation doesn't matter once you've taken your full current situation into account. Your best plan only depends on your current alternatives, which will influence future outcomes.

How does this play out in practice?

In practice, people do take sunk costs into account. Once you've embarked on a course and spent time and money on it, it's common to want to continue down that path, even if that's no longer the best coures at some point.

When the sunk cost weighs on a selecting a future decision, we refer to this as the sunk cost fallacy or sunk cost bias.

Why do people do that? Here are some common reasons.

• A desire to be seen as confident.
• A desire to be seen as consistent.
• To avoid acknowledging that a prior decision was incorrect.
• To avoid "wasting" the sunk costs - read more here.
• Groupthink, leading to lack of critical thinking and more conformist thinking.
• A desire to "stick to the plan" and avoid challenging and revisiting prior conversations and decisions.

A specific, well-known example was the Concorde fallacy, where UK and France continued to spend money on the project even after there was no case for it.

How does this apply to software development?

This one we can figure out from first principles - you might see this anywhere that costs are incurred.

• Time spent writing code. We should keep this implementation around!
• Time spent writing tests. We should be running them as much as possible!
• Time spent fixing bugs. This means the code must be better!
• Time spent learning a new framework/language/library. We should put it to use!
• Time spent learning a new methodology. We should learn how good it is!
• Effort spent building a component. We can fix our own bugs and add our own features, we shouldn't replace it with a third-party one!
• Effort spent building an app. We should keep it runnina and ship it!
• Effort spent maintaining coding or design conventions. We should not deviate it!
• Started a rewrite for an app but it seems there's far more work than initially thought. Need to push through and finish it, otherwise all the work so far is wasted!

Now, I'm not saying that any of the follow-up exclamations above are always wrong. But they aren't justified by the effort put in the past!

Ignore your sunk costs, and happy swimming!

PS: The Behavioral Insights Team, funded by the UK government, has a very nice review of sunk cost bias and some other biases that can affect project decision-making over here.

Tags:  management

Home