Picking tech stacks

I realize now that one of the hardest parts of running a successful startup is “betting” on tech stacks that, 3 years out, will have a groundswell of community support around them.

It’s still shocking to me that when I chose each of the following technologies as a central part of Parse.ly, they were so new/immature as to not even show up on a Google search trends box, but are now very popular technologies.

Each of these also now has several O’Reilly / Manning books and very active open source repositories with lots of outside contributors.

This is what technologists mean when they say they deal in uncertainty every day. I could have just as easily have chosen technologies that would now, in 2015, be totally unknown and/or unmaintained. There are certainly no shortage of alternatives to these technologies.

3 thoughts on “Picking tech stacks”

I’m curious if you are, this year, starting to use any technologies which may or may not succeed in the next 3 years? You write “This is what technologists mean when they say they deal in uncertainty every day” but surely it is something of an exaggeration to say “every day”. I’m curious if you view these decisions as “once every 5 years we will pick a new set of technologies” or whether you sincerely feel that you are, every week or every month, betting on new technologies that may not work out. If the latter, I would be curious about what your most recent bets have been.

I’d say the new technologies we have picked up recently that are important enough to qualify as “bets” are:

Elasticsearch

Python 3

AngularJS

We feel a little uneasy about each of these right now.

I don’t think that the situation is as risky as it was in 2012. Each of these technologies is already well-known. Ironically, Google Trends indicates that AngularJS is the most queried of all of these, but AngularJS is also the one I am most concerned about from a longevity standpoint due to the rapid rate of change among JavaScript rich app frameworks!

With hindsight, any example of what might have been a bad choice back in 2012?

We went pretty heavily with MongoDB in 2013 — fortunately just for some small one-off projects like focustwist.com — which in hindsight I’m glad we didn’t end up tied to (although in fairness it sounds like some of the major issues we ran into have been fixed more recently).

At Knollop (now learnstream.com) we’ve always used Scala+Play very heavily, which my cofounders like a lot but I have never really bought into. To be determined how that one plays out…