We're often faced with decisions that we'll have to live with for a long time.
What language should we write our application in? What framework should we use?
What will our architecture look like? We spend lots of time and effort
in trying to find the right answer, but we often forget the alternative: instead
of making this big decision, could we make the decision irrelevant?

Suppose you need to pick a language to build your system in. This is tricky
since it often takes months or even years to discover all the annoyances and
issues of a language, by which point rewriting the entire system in another
language is impractical. An alternative is to split your system up into components,
and make communication between components language-agnostic, for instance
by only allowing communication over HTTP.
Then, the choice of language affects only a single component, rather than
the entire system. You could change the language each component is written in
one-by-one, or leave older components that don't need much development in their
original language. Regardless, picking the “wrong” language no longer has such
long-lasting effects.

This flexibility in language isn't without cost though – now you potentially
have to know multiple languages to work on a system, rather than just one.
What if there's a component written in language that nobody on the team understands
anymore? There's also the overhead of using HTTP. Not only is an HTTP request
slower than an ordinary function call, it makes the call-site more
complicated.

Making any big decision irrelevant has a cost associated with it, but confidently making
the “right” decision upfront is often impossible. For any big decision, it's
worth considering: what's the cost of making the wrong decision versus the cost
of making the decision irrelevant?