Saturday, April 22, 2017

Sunk Cost Fallacy in software development

I am working on a project having to do with government certification. One of their requirements is very odd, so we've had to put time an effort into doing design and research into how we could best meet the odd requirement. Given that this is for a government certification, the requirement is set in stone (or so we thought...!). We thought we simply misunderstood their requirement, and so we figured out two design alternatives - one that was simple based on what we thought they meant, and the other based on if they truly required this weird thing.

We got clarification and they truly required the weird thing. We accepted this, and spent 2 weeks on the design / proof of concept work that takes place before actual coding. That included review meetings with the top dogs in the company. So alot of time and effort was put into this design. 

The design was approved and the stars were aligning, code was about to be slapped into an IDE. But then at the last minute the government changed their requirement (weird, that never happens in software development!). They gave us a choice - we could do the weird requirement or the smart requirement, and we'd just need to tell them what way we chose. 

So now we're at a fork in the road:
  • Go ahead with the coding on the already-completed design, even though the road ahead was a long nasty one
  • Do the simple design approach, taking a day or two to go through the approval process again, and then proceed with the very simple coding

You'd think the obvious choice would be to do the simple design approach, but that's where the Sunk Cost Fallacy comes in. Time and energy was already spent on the first design, therefore we should continue to invest in this design! Nope. The time and energy spent on the WRONG design does not justify going forward with it. 

Sunk Cost Fallacy teaches us that the smart thing to do is cut our losses, and not be fooled into thinking that previous resources spent justifies continuing to throw resources at the wrong solution.

We did end up going with the simpler design, but that's because we were aware of the Sunk Cost trap, and were able to avoid it and make the wise decision.

No comments:

Post a Comment