DEV Community

Discussion on: Do you have any bad “sunk cost fallacy” stories?

Collapse
 
tadman profile image
Scott Tadman

The biggest sunk cost fallacy comes from lock-in with a vendor or platform. Switching costs can be incredibly high, we understand that, but we're also terrible at estimating the on-going cost of not switching.

Collapse
 
bgadrian profile image
Adrian B.G.

I think that the biggest lockins are made with the Languages, frameworks and databases, so big that teams stuck with bad decisions for decades and refuse to admin that the requirements changed.

The vendors and platforms can be easily changed, most public services are very similar in behavior.

Collapse
 
tadman profile image
Scott Tadman

"Similar" is only superficial. For example, PayPal and Stripe offer similar features, but the way they work in practice is completely different. If you build your business on top of one it's not necessarily easy to switch. PayPal does things Stripe doesn't do, and vice-versa.

The key difference here is that programming languages and many frameworks are run by organizations committed to improving that product for its user base. Their priorities are centred around making the platform better.

Any "software as a service" company is focused on building their business and they may make dramatic changes that aren't in your best interest. They may shut down their API for no reason. They may pivot to a new business model that makes their service prohibitively expensive. They may get acquired and run into the ground.

As one example, PHP will no doubt be around in ten years, and while the popular frameworks will no doubt change between now and then, any framework you pick now will still exist then even if it has a much smaller user base. You can always patch and update it yourself if necessary.

The same is not true for that SaaS that looks so amazing today. It might be completely gone in ten years.

Thread Thread
 
bgadrian profile image
Adrian B.G.

It is true, but ...

most projects I've seen on APIs can be switched around with a few weeks of dev hours.

For example Paypal and Stripe can be easily be replaced in most websites I know, sometimes with a simple click (install different addon). We moved from Parse to a custom API in 2 weeks I think (when it failed).

What I meant is:

  • the downsides of a language/framework on the long run are way more devastating and limiting (see Instagram/FB with their PHP for example)
  • the SaaS are limited to one feature usually of the project, cannot affect in most cases the entire project, you can switch them in small steps/soft releases/ab testing
Collapse
 
perttisoomann profile image
Pert Soomann

Ah, interesting. I have completely opposite experience, where most of the languages and platforms offer similar results, one way or another, so picking any one won't make difference long run, but it's the internal business logic that becomes an issue and can't be easily changed, part due to code structure, but more so because of existing business logic.

Completely agree about 3rd party integrated services, these companies can close down or be bought and change their business model completely, so that's always a risk.

But in the end I think it's more important to be able to adjust and jump on new business opportunities than to worry about tech stack.