Choosing your next technology stack

“Hey, let’s use Framework X that was just released a few weeks ago. I read that it’s much faster than what we’re using now.” - RockstarDev2015

“Oh, but did you see the recent benchmarks against Library Z. It didn’t look that great at all.” - I_Am_Ninja

We would have probably started and / or participated in similar conversations when deciding on solutions to use in our product’s technology stack.

But let’s face it, are these really the type of questions that should dominate the discussion surrounding the topic of which technologies we should adopt for our product?

Sure, they are important points to consider, but my concern with these types of questions is that they are often asked in the absence of context pertaining to the product we’re building.

Thus, before tackling the technical qualities of the proposed solutions, I feel that it might be a good idea to consider a couple of other aspects.

Community / Ecosystem

Surrounding every popular framework are groups of brilliant engineers who make up its community and in choosing to adopt this particular solution, we will inevitably be interacting a lot with these guys.

Some things to ponder upon:

  • Is there mutual respect amongst everyone in this community?
  • Moving forward, what are the plans for the framework?
  • Who are the guys using it in production? Do they share similar technical challenges as we do?
  • How active is everyone in contributing (be it writing tutorials / plugins / answering questions) to the project?
  • And most importantly, do we want to be part of this community?

These are, in my opinion, important questions worth considering when it comes to evaluating a solution for use in our technology stack.

But, if I were to pick the most important criteria in selecting a framework, it would be this.

Developer Productivity

The number one reason why I would be more inclined to choose a framework over another is if it improves our developers’ productivity.

Some other framework(s) could be more performant out of the box, it has been battle tested by massive companies, some of the greatest minds are behind it, it’s modern and hip…

But if it ends up making our lives difficult, whether it be because the team is not experienced in, or finding it hard to understand, the philosophy behind the solution or that there is a really steep learning curve. All it does is that it leads to poorer code quality, longer turnaround times to ship new features, leading to non-existent value-add to our users.

Hence, the only benefit in adopting such a solution, is that it makes ourselves feel good, because we’re using the latest and obviously coolest technology solution.

Admit it, we’ve probably done that at some point in our careers.

Truth is, it really doesn’t matter if we’re using hipster.js, some cutting edge service written in 10 lines of code, a persistent storage system that’s webscale, or whatever.

In my honest opinion, what’s most important is that our chosen stack is one that complements our team’s collective experience and knowledge, resulting in better productivity levels and most definitely, happier developers.

So, if there’s no synergy between our chosen technology stack and the team of extremely bright engineers that we work with, what’s the point?

Don’t pick the solution that makes you look cool. Pick one that enables you and your team to build a great product for your users.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.