Shiny New Thing

日本語はこちら。

Deciding on what software, programming language, framework, library to use a huge challenge that all software engineers face when developing. The decision requires a lot of thought and consideration. Starting from the obvious, "Does it do what we need it to do?", to the more subtle, "Does it have a large community?", "Will it be there next year?".

Even though we all know it's a hard problem, I still see engineers jumping on to the next, new, shiny thing. I've done it myself too. I'm sure readers have seen or done similar things too. It's a realy easy trap to fall into.

I'd like to shed some light on the problem and hopefully help people make better decisions in the future.

Shiny New Thing

When deciding on new software/programming language/framework/library to use, it's very easy to pick up the "Shiny New Thing". I believe people have a natural tendency to think that new is better. The new thing touts all the new features and how it's better than the old ones. It's yet another thing that you have to know, you can add it to your resume, you can talk about it in your next interview.
Great! Let's npm install/pip install/gem install it. You configure it according to the README, it works fine, it got the job done. You're happy, you know the cutting edge technology!

So what's the problem?

Problem 1: Edge Cases

The first problem is that the tool may not covered all the edge cases. It might work fine for the case you want to deal with (probably will because you're looking for something based on that case). But is that really the only case you have to deal with? When you are in your early phase of development, you don't necessary have all the cases you need to deal with laid out. This means whatever new thing you pick may not be able to deal with the edge cases you haven't thought of yet.

Problem 2: Market Position

The second problem is that the new thing may not have found its position in the market yet. Things that age well typically have found it's position in the market. It solves a case where many people are experiencing and continue to experience.
It may seem like the new thing has solved a case but you can never be sure that it solves a case for "many people" who will "continue to experience it". If it doesn't, it may not be around for long.

Problem 3: Hiring

The third problem is that it may be hard to find people who know the new thing. From a manager's perspective (which I am), this is not a negligible problem. It's likely that there's nobody else on the team who knows the new thing and leads to instability in the team (bus factor = 1). And worse yet, it's not going to be easy to find people who know the new thing.
Even from a personal perspective, you probably want to avoid this. You may think that it's not a problem because you think you can deal with it but there's zero guarantee that you will and you'd want to (are you sure you would want to deal with it in five years time?).

So I Cannot Use New Technology?

Yes, you can. There are cases where you need to use it. There may be no other way to solve the problem.
As with any other problem in software engineering, "it depends". The problems I've stated may 1) not be a problem under your circumstances, 2) nobody can predict the future and thus you might even end up being right about using the new thing.
The key is that you need to be mindful of the risks (like the ones I've mentioned above), weigh it against the benefits of the new thing and make a decision.