That article was about the “sunk cost fallacy”, it’s what happens when you are biased towards an option because you made an unrecoverable upfront investment into it. Be it time, money, or whatever you perceive as valuable. An example: you bought a ticket to a movie you were later told was awful, but you will go anyway because… hey, you paid for it. The fallacy is that going will eventually make the matter worse (wasting your time), and won’t help recovering anything.
This is also called “The Concorde Fallacy”, and I think this makes a nice transition to the programming manifestation of the issue. That aircraft was an amazingly cool technical and aesthetic achievement, but it was also a major commercial failure, and one that was seen coming from afar. Killing it half way would have made a lot of sense, but how could such a difficult decision be taken? Cancellation would have been an acknowledgment of failure. Moving forward, as expensive as it was, was the path of least resistance.
Crafting code takes time and dedication, so when we are finally happy with our work and confident about its reliability, we usually do our best to stick to it. But at some point choices made will start to be questioned, and we will wonder if the design was the right one, if another approach would not be better.
That kind of debate arises frequently on a lot of different scales, be it just you arguing against yourself on your own code or a company-wide discussion about the technology to be used on the next big game.
And this is where the perceived value of the technology at our disposal can be deceiving. This technology did cost man years of labor and heaps of money, but as it is, it has no value by itself and should be considered as such. The one thing that has a lot of value is the knowledge your team and yourself have and gained through this technology. It will often be deeply rooted within that specific technology, but sometimes not.
So the real question to ask is: given what we learned so far, what should we use? If that means we keep on using the same tech because the team knows how to get the most out of it, that’s fine. It that means the abandon of a large part of the hard work done through the previous years, that’s fine too, knowledge and lessons learned through failure are never lost. If that means moving to another better tool or engine that your team feels more confident with, it is also great.
But always be careful of being biased towards an option only because it was hard to get to. Just because you got it does not mean you will loose anything by going for something else. Of course, the world is not all black and white and there are many forces at play, but I only wanted to question if technological choices are always as rational as we think they are.