Choosing the Right Tech Stack

A lot of times, programmers looking forward to prototyping their projects are faced with a common dilemma, “Which framework or library to choose?”

Choosing the right tech stack is essential in designing a well-architected solution. While there are a plethora of advantages that emerging tools and technologies bring along, they also make the process of finding our niche more convoluted. For example, there have been times where I would simply google ‘Angular vs React’, see a random youtube video comparing the two, and finally start coding my project on ‘Vue.js’. Based on my experiences as a student developer and a Software Engineer, I hope to share some thoughts on this topic.

Right of the bat, the most important point to be considered would be the context in which this question is asked. More often than not, you would have to change your preferences based on factors that aren’t usually in your control. I had always been in the comfort of knowing that I can somehow google stuff and make things work without having to know the nuances of a tool. However, there have been times where I’ve regretted my choices and took weeks just to create a boilerplate code. Without further ado, let’s look at some points which, in my opinion, need to be considered before making your choice.

1. Functional requirements, the project scope, and the time to deliver the product — If any of your choices tend to jeopardize these aspects, it is a bad idea to use them.
2. Your proficiency in understanding the architecture and using the language your framework demands — As an example, Flutter is a great toolkit for cross-platform mobile development. However, are you okay learning Dart?
3. Availability of official documentation and community support — If StackOverflow can’t answer our questions, then who can? 😜
4. Interoperability and compatibility with legacy systems - This is far more important than you think while operating in the industry
5. Performance and the ability to scale up, both vertically and horizontally.
6. The effort required for “forward compatibility” — Some systems are updated way too often and expect you to re-write your code every single time.
7. Availability of 3rd party libraries and SDKs for the services you might want to integrate with.
8. Cost and terms of usage — Beware, technologies that are free for community use might cost you a lot when used commercially.
9. Last, but not least, you need to be in consensus with your team. After all, engineering is always a collaborative effort.

While I’ve made a conscious effort to keep these points generic and platform agnostic, a few of them can be safely ignored. Students might not have to worry about performance or long term maintainability. At times, experimenting in uncharted waters can be more rewarding than sticking to the “best practices”. Nevertheless, It’s okay to fail fast, as long as we are agile in our thoughts and actions. Please share your experiences and I’d be glad to learn from them.