How to pick technologies for your next project using the 3M framework
Instead of relying on GitHub stars
During my past six years of software consulting, I built and shipped apps for industries such as AEC, HR, gaming, and finance.
Why the emphasis on ”shipped”?
When you have to deploy software in production and maintain it, the steps you take to pick technologies drastically change compared to when you’re looking to build a weekend project.
In this issue, I’ll present my 3-step framework: Matury-Membership-Modernity for picking tech.
For each M, I’ll discuss:
why I rely on this indicator
a personal story – what happened when I ignored the indicator
an emergency exit – how to live with the tech, in case you already picked it
If you like this content, subscribe by clicking the link below. All issues are free and action-packed. I guarantee you’ll read something you’ve never read elsewhere. Thanks!
➡️ Key Takeaways
Build on top of tried & tested systems.
Make sure you’re not alone. Check the community, docs, and support channels for the tech you want to use.
Choose tech that constantly evolves. Modern solutions attract talent, and nobody likes to work with the hottest technology of the past decade.
Here we go!
🦕 Maturity
How long has the technology been around?
I consider this one of the key decisions when choosing a technology.
Early versions are almost guaranteed to hold surprises for you, unlike something that the community has widely adopted for decades.
But being mature isn’t a guarantee either.
Like cars, a 13th Generation Toyota Corolla won’t have any problems from the 1st Generation. Still, since the entire car has pretty much changed, you might face an issue that wasn’t a thing in Generation 6.
But it’s a fact that they had 13 generations to refine not only their car but also their development, testing, and shipping process, so it’ll hold a lot fewer surprises than a 1st Generation model.
🧙 A personal story
In 2017, I picked a relatively new and popular technology as the base for a Saas that we launched in 2018. This framework was deprecated in 2019. Key maintainers decided to go on separate paths and create different flavors of this tech, but nobody fixed the issue in the original framework.
The result?
We were stuck with an old Node.js version and many known issues that won’t be fixed.
🛟 Emergency Exit
I often ask myself, how easy is it to migrate away from a tech if we have to?
Despite being new in 2017, this framework I picked was an extension of Webpack (a reasonably mature technology). It allowed us to “eject” the Webpack configuration, essentially removing the dependency and continuing as a pure Webpack-backed app.
Relying on maturity is vital because tech keeps evolving, and new problems are introduced.
Maintainers, or the community, if it’s open-source software, must deal with those problems.
This is why the following indicator is crucial.
👥 Membership
When you ”buy into” a software solution, such as React, Next.js, FusionAuth, or TailwindCSS, you become a member of their online space.
Explore the community’s vibe before picking a technology. Here are a few good indicators:
Is the project being actively developed? Check when was the last commit.
Is the documentation up-to-date and comprehensive enough?
Look at the activity or their Issues page (if public). Are the requests answered?
Do they have a separate community forum, GitHub Discussion, or a dedicated StackOverflow tag, Discord?
Exploring the different ways to get your questions answered once you’re stuck is essential. You might never have to use any of these channels, but at least you know what you’re up against when stuck. I forgot to check this…
🧙 A personal story
On client request, we integrated a 3rd party API a couple of years ago into a SaaS. The community around the API had red flags:
First, because of its size, the documentation was constantly refactored. Things were renamed, lots of documentation pages gave 404, and the response examples they supplied were so outdated that we had to inspect their responses and write our schemas and types.
While their GitHub Issues page was open, they redirected people to StackOverflow to ask questions under a specific label, which, if you know StackOverflow, has limitations, especially if you’re a new user.
🛟 Emergency Exit
Find the key people who have already explored this technology and ask for help.
Someone might not have a StackOverflow account, but they have X or LinkedIn and are happy to share a solution.
If they charge for consulting, that’s fair. But if they help you for free (essentially all OSS maintainers), respect their time and be grateful.
😎 Modernity
Mature and Modern are not exclusive attributes.
Some mature technologies are decades old but remain fresh and attractive to new engineers.
Picking an attractive technology is essential when you think about acquiring new talent.
And new talent is crucial for software companies to stay ahead of the competition.
Just consider yourself.
Would you work for
Company A: ”We use Java 21 for development”.
or
Company B: ”We use Java 8 because of compatibility reasons.”
🧙 A personal story
One of the most significant refactoring projects I’ve worked on lasted for over two years, and it was about converting an entire HR solution UI from Backbone.js to React.
Why?
Because nobody was learning Backbone.js anymore.
It wasn’t attractive for engineers, and there were better technologies that people were already learning anyway.
🛟 Emergency Exit
It’s challenging to have one in this case. You don’t know if something is about to get replaced because of a breakthrough or a broader adaptation of a new technology, so you can’t effectively prepare for this.
However, you can keep an open mind, and if something emerges as a new go-to tech for some tasks, as React.js did for front-end development, try to integrate a POC into your current solutions.
This is exactly how we tackled the above migration. We figured out how to render React inside Backbone.js pages and migrated the app component by component.
That’s it! I hope you found new insights on picking the best technologies for your next project.
I appreciate everyone sticking with my newsletter. 🙇
What are your indicators when picking technologies for your projects?
📰 Weekly Shoutout
💻 Remote Work vs In-Office Work. What’s best? This is a hot topic, and there is no right answer. If you’re lucky, you can experience both.
sharing his experience with you in this article.Improve your SQL skills X2 in 5 minutes – I always considered it essential to be hands-on with tech no matter where you’re on the Engineering career ladder.
shares with you what separates casual SQLers from the pros!Why Write Small Diffs – Getting an LGTM on a PR is my worst fear 😅 and I do everything to avoid that. Making smaller PRs is the first step in this direction. Read some more great reasons from
on why to write small diffs.
📣 Share
There’s no easier way to help this newsletter grow than by sharing it with the world. If you liked it, found something helpful, or you know someone who knows someone to whom this could be helpful, share it:
🏆 Subscribe
Actually, there’s one easier thing you can do to grow and help grow: subscribe to this newsletter. I’ll keep putting in the work and distilling what I learn/learned as a software engineer/consultant. Simply sign up here:
Very interesting framework! It was new to me. And I loved the personal stories :)
I find that the best indicator is the frequency of commits. If the last commit to master was 2-3 years ago - that's a huge red flag.
And thanks for the mention!
Thanks for the mention, Akos!
Taking dependencies is like committing to a relationship. There are always new potential partners. But at the same time, nobody wants an unstable relationship...
I didn't know the 3-Ms framework and it's interesting to make sure we make a balanced decision