This is a post about choosing a technical stack for your project/ product. This is not a recommendation for any particular stack, but is rather a look at some of the common mistakes that are made while deciding a technical stack. Consequently, this is a “what to avoid” kind of story. While I am mostly speaking of a technical stack, this can be extended to any tool that you are considering.
A few months back, we were having a rather passionate discussion regarding the technical stack for our product SocialConnext. I could not help but feel grateful for having solved a similar problem before. I was fairly confident and knew that the tools I was advocating would actually get the job done. But it is not always possible to be certain.
There is a lot at stake with this gamble: time, money and probably the very existence of your company. So, how do you stack the deck and swing the odds in your favor? Of course, there is no simple answer. A lot of it boils down to experience and expertise. However, over the years I have seen some very avoidable mistakes that are often made.
Let us see some of them, shall we?
You and Me: Forever
Unfortunately, this is something that I have seen way too often. Typically, the technical architect/ head has a preferred language/ framework that (s)he sticks to, no matter what. The fit is never examined; instead the only questions are how do I solve the problem with my framework or how do I make my favorite database scale to meet these needs. If pressed, the most common excuses you are likely to hear:
* There is no skill set within the team, it is easier to solve the problems than investing the time to learn a newer technology
* It is too hard to build/ hire a team with the necessary skill set
* We can rewrite the code if we run into problems later on
This myopic view can be really harmful. Familiarity, while useful must not be a major decision maker. A major rewrite not just kills momentum, but also leaves you with having to deal with crumbling infrastructure while you desperately need to grow. Also, if your team can’t pick up the necessary skills in a meaningful amount of time, are you really working with the right team?
Newer and Shinier
The Silver Bullet
However, it is important to remember that there is a reason that the other side of the aisle is so popular. Do you need a lot of native app features to gain a leg up on your competition? Would a MVC pattern better suit your needs? Can server side rendering help you scale effectively? In a quest for a silver bullet, don’t shoot yourself in the foot.
Going in Blind
We have all been there. There are pressing needs; you just don’t have the time to properly research and figure out things. You do a cursory google search, read a few novice opinions and make a decision. While this kind of judgement is typically done at the level of minor tools (like say, a job framework), the consequences can still be really bad. Even when pressed for time, always do the necessary research. Try out the tools and see if it is something you are comfortable with, especially if it is something critical for your application. If you are relying on somebody’s blog or opinion, do look up their credentials. In my experience, the time spent researching at the start has proven to be worth it’s weight in gold.
Take the Plunge
That’s about what I can think of. If you think I have missed any, do share them below. Choosing a good tool really boils down to: taking your time, doing the research and having the right people make the critical decisions. Do ensure that your technical partners can give you a convincing answer as to why they choose a certain technology and what the alternatives are. Once done, take a deep breath and make the plunge. Best of Luck!
About the Author