Choosing a tech stack, framework, library seems to be simple problem to solve - you take the best one available on the market.
The problem is that there is no such thing as the best tech. It all depends on the context and most importantly on the problem you are solving.
When building a proof of concept or an MVP - the reasonable choice is to use something that let you build things rapidly, tools that just lets you validate your assumptions, get funding or whatever short term goal you have.
Working for established company or in a project with long term goals requires different thinking. Below is the list of things - built collectively on Twitter I believe you should consider before making any important choices:
- 🤷♂️ if existing team is familiar with it
- 🕜 how long will it take until they learn it
- 🤯 how tough will it be if the most experienced person leaves
- 👷♂️ how much maintenance does it require - is it managed or you need to take care about backups, updates, keeping it alive
- ⚡ do you value more the powerful features or the ease of use and high team velocity as a result
- 👩 who's behind it. Will it be around in few years?
- 🏍️ how hard will it be to replace with something else in the future?
- what is the track record of the provider for maintaining backwards compatibility and easing upgrades? (thanks Corneil)
- 🤝 is it open source, how big and active is the community behind it? (thanks Ania)
- 📚 what's the quality of documentation? (thanks Ania)
Bringing all these questions to the group may end up in endless discussions - everyone has a little bit different view on quality and complexity.
Discussion around these kind of topics needs a structure - the best if the structure is optimised for focusing on important parts and skipping the "personal preference".
I find technique called Architecture Decision Records not only a great way to document significant architecture decisions but also a format that structures the discussion around the problem.
It's important to keep tech stack relatively small. Don't use something because it's cool or because you want to learn it - in the end it may have long term consequences for the team or whole company (unless you're a solo developer or it's a proof of concept/MVP).
There are no silver bullets - every choice comes with pros and cons - and it's ok, let's just do our best to be aware of them and the consequences before the actual choice is made.
As a general rule I aim for simple tools first - complexity is a velocity killer 🐌.
You can get really far without using any top tech considered nowadays as "industry standard". Pieter Levels built $1M business using plain PHP and jQuery - just by himself.
Keep It Simply Stupid.
