We can’t stop now, as we already invested 1x in it, but let’s proceed to spend 100x more over the years! STONKS!

The Javascript example

You might have heard it before, but Javascript was written in 10 days. It had a rapid growth of adoption and they didn’t want to introduce breaking changes even after some years of using the language… so, now the language is almost 30 years old (remember it's from 1995!) and we still have to deal with those decisions.

They knew way back in the early years of JS that there were a lot of changes that would benefit the language, but didn’t want to break the “countless” websites from back then (there were a couple of million total websites worldwide back then, not necessarily using JS at all!).

Hindsight is 20/20, and they might have broken JS in a way that wouldn’t be what it is today.

Then again… Angular did just that when breaking and launching “Angular 2”. Just because many people were using Angular, they knew it was not sustainable to keep going with AngularJS, so they started to phase out from it to Angular2 and Angular got better because of it.

Would you invest in this today?

When investing, we feel like “losing” or “quitting” by jumping ship, but the people who can go farther are those who know when to quit a bad decision (not necessarily bad, but things change over time).

Back to the Angular/JS/2 example. Some companies are still using AngularJS, even though it reached end of life and some more some years ago. Now, they have to support and patch it on its own as they increase their codebase and make the decision to stick to it more and more painful and harder to change because of all the investments in it.

Of course, on the other side of this are people jumping from fad to fad and creating monsters that show whatever tech was more popular at each time, some that just stopped being used once people tried to start using it or that, some reason or another, just died and stopped being maintained.

The name of this is the sunk cost fallacy

You think you’ve invested “too much” already, so you can’t back down. You also think you don’t need the new shiny things if the boring old LAMP stack is enough and working.

But one thing is “it works” and another is: “in the long term, this will cost more than changing”.

In the financial sense, some new thing might let you go faster and farther, or at least, will let you be free to pursue other opportunities you might have missed otherwise.

The COBOL example

Banks run on COBOL, it’s been decades in “decline” but at each turn, they say it’s worth more to keep their COBOL legacy and hire COBOL developers at higher and higher prices than it is to work on migrating from it. TBF, hopefully, they are strangling their legacy. But if they are still actively developing in COBOL, no LLM will help them when it starts costing prohibitively more to hire COBOL devs in a market with fewer and fewer available people.

Meanwhile, new competitors without that legacy can enter the market with other stacks that let them move faster, cheaper, and with a bigger hiring pool available.

Should you? When?

The analogy is that of steering a huge ship. When you turn the ship’s wheel, the change is not immediate. You need to prepare beforehand and there are strategies to make this easier. Then it will still take some time until it’s clear that yes, the ship is turning.

ROI

But coming back to the financial analogies: ROI (return on investment).

You use ROI to calculate which investment is better, usually comparing the one you’re assessing against a “base” investment.

This would mean calculating how much time is “wasted” by keeping the status quo against the estimated gains from the proposed change. Of course, you would need to add the time spent on the change and with that, you would get some number of how much time it would start netting you “profits” on that investment.

If the calculated gains are so small that it would take a long time to take effect, then it might not be worth it.

This one was about time spent on a task, but you can also use other metrics like accessibility, security, and reliability… if you can measure something, then it can be used to justify a change.