Development Context
Lets state an hypothetical use case where you are hired as Technical Leader or Software Architect on a startup that has a product (web platform) for a given purpose (the details here are not important).
The company has its product on the market since some months ago and getting earnings from that but they want to create a new product to integrate with the already existing one and asks you to make a preview analysis and choose which technologies (language, architecture, platform etc) should you use for that given new product.
Decision Making
In fact, the technologies to use are not a decision on "what you/they like most", you have to back your decision with that preview analysis which must contain some points that I'll try to summarize:
1- Developers experience
We assume you already have some developers hired so you have to keep in mind their experience with different languages, their experience developing for different architectures and their overall experience developing at all.
Also speak with them and know their opinion. There are people that don't want to change. If a person spent 20 years developing with Java or in a .Net environment, he/she may not want to go for a different thing and learn a different way to work, if it's the case in your team, ask them to make a decision.
If all your team agrees with including new/different technologies it's OK, but if not, take it in mind.
You also can set people that don't like changes to maintain old software while others develop the new one.
2- Knowledge proximity
This means that you need people knowing this technologies close to your companies office.
You will need to hire some developers after all and not having people next to you that know this technologies could make the process of hiring much harder or making it impossible to hire senior devs. Starting a project with junior developers only is a situation where no company wants to be for obvious reasons.
I started the draft of this post long time ago and now we have accepted REMOTE as a good option to offer in companies, a must. But there are people that don't like remote or they just like to socialise once or twice a week at the office, so the previous paragraph still makes some sense.
If we take remote as the base way to work then you need to take care of the time zone, so team members can interact with each other at least a certain amount of hours a day, it's difficult to sync teams if they don't overlap at least 2 to 4 hours a day.
3- Usage
Haven't you asked why some technologies you try at home are not widely accepted quickly?
I remember trying Svelte.js with and without Sapper and thinking wow I'm really enjoying this: Automagically routing directory based, vanilla js (ES6), nice hot reloading...
Then we started a project on the company I was working in and we ended using Angular and React on the next two projects with different needs.
Why? When there's a language/framework that it's not widely used it's difficult to find developers with experience on it.
Also It's a bad signal because the technology could be discontinued and then you will have two options: Fork the project and maintaining it by yourself or rewrite the project into a different language/framework.
Both options are expensive and you can avoid this by just using something backed by a big company, a very big community -or both- and widely used around the globe.
That's just it, reducing the risk.
4- knowledge of the reason to be for these technologies
Every year a big (very big) number of frameworks, libraries, utilities, compilers, languages and so on roll out to the public on git repositories, with nice landing pages along the promise of solving a real need.
Languages and frameworks appear for different reasons: cost of scalability, cost of development, retro-compatibility, hosting costs, cost of maintainability...
It's all about reducing what it takes to reach something so freelancers and companies that by using those tools can reduce in costs overall.
You need to analyze the details of each to find which fits best for your project.
The bad decisions about all those points are sometimes called OverEngineering too. That's because using java and sql server for raising a static landing page it's a financial suicide. Why would you want to pay the minimum requirements for keeping your java app up on this conditions (minimum RAM for the server, another for your DB, higher core counts, disk space, nodes and so on) when you can simply code it with static HTML and CSS/Sass, wrap it all using a bundler and that's all.
You will be ok with a low core count, low ram count and less than 300kb weight on your hosting plus you'll get benefits on SEO and Core Web Vitals.
On the other hand I'll probably go for Java or C# for the micro-services and a Node JS gateway for a banking WebApp, to add another example without digging too much.
Those are the 4 key points we don't mind from the developer point of view but that are important to consider when you manage a project or rule a company. What other key points do you handle?
Top comments (3)
Good article!
Thanks you! 😁
Thank you! 😄