programming

When discussing a new technology, I’m rarely the first one to jump on the bandwagon. In fact, I’m usually the killjoy that ends up arguing against using a new library or a new language feature when the enthusiasm is high and everybody is eager to get started.

It’s not that I want to stay comfortable and never move forward. Rather, I need to be convinced that something is worth it instead of moving for the sake of it. New features and libraries can add complexity to something that’s already complex. That makes it harder for new people to join in (including you if you didn’t touch it for the last 6 months).

I’m all for new ideas that makes software easier to understand and that allows me to do my job better. Still, the argument about new technology is too focused on the shiny new technology itself, and not the problem it solves. A great idea is not enough; it has to work well in the real world.

To illustrate this, I choose a few templating engines at random on npm (not judging their quality; maybe they’re all great). Here is the kind of descriptions that will greet you:

Why should I choose one over the other, or use it to replace an existing tool?  A description like fast and powerful is not very helpful. It’s good to have, but who would pick a underpowered, slow engine?

Of course, if I’m looking specifically for an HTML template engines I can narrow it down a bit, but if I don’t have a strong preference one way or the other, what should I choose? There were surely a few problems or use cases that led to writing those engines instead of using an existing one, but I don’t have any way of knowing from looking at this.

At this point, I’m asking myself if the library will still exist in 5 years (without forcing me to rewrite everything every year) and if it’s well documented so I can get up to speed quickly, not if it implements a cool pattern in particular.

If I had to choose something for a project from that list, I would probably pick the ones that have the most promising documentation and a large following, and try them out for myself. Granted, it could still blow up later in production or when trying to implement a feature in particular since I’m only coding a prototype, but it’s better than nothing.

But after doing all this work, why would I switch to something new a few years down the line if the one I choose first still works well? I have to be really convinced that it can solve my problem better, and that is worth the cost of switching in improved productivity and ease of use. With the speed that the technology is moving I must be sure it’s worth it. I can’t afford to waste my time migrating to something that will make things worse.