Did we back the wrong horse?


Here’s a question one of my clients asked me a little while ago:

How do you spot that you need to come off a specific [JavaScript] library?

As always, this question is not without context. In this case, this organisation is responsible for a variety of products, each with different needs. They had adopted a view component library a couple of years ago that is now no longer popular. The fact that they asked the question at all reflects a growing unease with the choice.

I’m not going to answer their question today. Instead, I want to make the point that it’s important not to act rashly in this situation.

My client are rightly questioning the choices they have made. They are responding to growing discussion and feedback from developers that there may be better options. But they are also wary of making a big change without doing the due diligence. After all, this would impact a lot of their teams, and they don’t want to make an expensive mistake.

Sometimes in these circumstances, a decision can be made almost by accident. For example, a single developer may create a ‘proof of concept’ using a different library or framework. This may be seen by others who don’t realise that it’s not yet officially ‘adopted’ technology, because no official path to adoption exists. So in the absence of any other strong decision, the library becomes adopted de facto. This is similar to how new words are invented and are enshrined in dictionaries only in hindsight.

In other circumstances, a decision can be made unilaterally. A new tech lead may assert their authority and push through a change without much consultation or experimentation to understand whether it is a good fit. This is not always a bad thing, but it often is.

In any case, it’s important not to react to signals like developers grumbling about better options, proofs of concept, framework hype on social media or the narrow experiences of one experienced developer. These are just clues. What you need is evidence.

Next time, we’ll look at an approach you can take to understanding how well your current technology choices fit with your needs.

In the meantime, tell me about a rash technology choice you’ve made or witnessed that backfired later on (without naming names of course).

All the best,

– Jim

Receive emails like this in your inbox

I write about front-end engineering leadership every weekday.

Sign up now and get my Front-End Engineering Responsibilities Laundry List PDF for free.

You'll get regular emails about front-end development. Unsubscribe at any time.