Rational technology choice doesn't exist


If you suspect a fundamental technology choice (like a JavaScript framework) in your stack might be due for a change, it’s time to back up those clues with some in-depth research.

Here’s some considerations to take into account:

  • Is the project actively maintained? Are issues public and actively triaged? You shouldn’t necessarily be worried about a large number of outstanding issues, but no triaging activity at all can be worrying.
  • Is there a continuing active community around the project? You’re looking for multiple project maintainers, lots of contributors, regular releases and plans for the future.
  • Are there long-outstanding security vulnerabilities that have gone unaddressed? How serious are they?
  • Is there a clear replacement that the community has moved over to en masse? Does it cover exactly the same scope? Is this just hype or is it reflected in true usage numbers? You’re not looking for GitHub stars here, or even NPM install stats. Libraries.io has a ‘SourceRank’ algorithm, but it’s not an exact science.
  • What specific pains is your team currently experiencing with the library? Is this down to the library itself, the way it’s being used, or something else entirely? Be sure that you don’t point the finger at a library or framework if the real problem is the spaghetti custom code all over your app. Switching tech won’t solve this problem for long.
  • What measurable user benefits would there be by switching? Clear performance improvements? Have you proven this?
  • Could you replace it with something you would maintain yourself, such as a forked version? What are the implications of doing this?
  • What impact is use of the technology having beyond software development? Are you struggling to hire people? Do you find yourself keeping quiet about it during the hiring process out of embarrassment? (This is not a good reason to switch, by the way, but it is a good reason to be honest!)
  • Does retaining the technology impact the adoption of other technologies? How so? How much of a problem is this?

You get the idea. This list goes on.

The point is, none of this can be boiled down to an objective rating, an impact measurement or a decision algorithm. Ultimately, it’s subjective. It’s a matter of judgement as to what applies in your circumstances.

It’s a qualitative decision that may have quantitative impacts. But you’ll be hard pressed to isolate the impact of this one decision as its effects will be felt over a long period of time.

But, that does not give you the excuse to make an uninformed decision. Yes, you’ll need to use judgement and experience, but you’ll need to gather as much evidence to support it.

Even more importantly, it’s better to make a quick decision that is reversible, than a reasoned and carefully planned decision that can not be undone. (I’m paraphrasing Jeff Bezos here).

For me, that means taking gradual steps and using hypotheses and experiments to understand the effects of making changes. Minimise the costs of making mistakes, but don’t avoid mistakes altogether, because you won’t.

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.