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.
As anyone who has tried to start/ run a business knows, you rarely end up with the product you had originally envisioned. You pivot to align with the market, your clients’ needs, your funding situation; sometimes you even pivot because of constraints placed by your own team. Also, if the rise and success of agile delivery has taught us anything, it is that things rarely go as per plan. You discover things that need to be built that you did not see coming. Given all this, when you choose a stack, really you are taking a giant gamble and pretty much going all in.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?
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:
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?
This is the other end of the spectrum. While, it is good to always look at newer technologies; jumping in to bed with the newest kid on the block can quickly lead to buyer’s remorse. A thriving, vibrant community around the language/ framework is not just necessary, but essential. Have similar problems been attempted in this framework? Is there evidence that it can scale to match your needs? Can your developers find the necessary support/ documentation online? Can you get/ train resources at the pace you need and under your budget? Are there sufficient tools/ libraries available or are you going to spend a significant amount of time re-inventing the wheel?
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.
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.
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!