Recently I’ve found myself answering a similar question: “What tech stack should I use? What’s the best programming language to learn?” The response always starts with: “It depends…”

The tech stack is defined as the combination of technology that makes your web application -- anything from your web server, to application back-end, database, and cloud provider.

There’s a couple of things to think about when choosing a tech stack, whether for a new feature, or new business.

Bleeding edge technology isn’t always productive

New and shiny technology is released all the time. There will be a following on Hacker News and Reddit, and it is touted as the next best thing. While it very much could be the next big thing, there are caveats to using any new technology. At the beginning, you’ll spend some time learning -- and the ramp up period working with something new may be better spent working on MVP features. Bleeding edge technology isn’t necessarily production-ready. Sometimes, the only resources that you’ll find are vendor docs or blog posts from people that haven’t put the tech into production. A simple blog example is a lot less complex compared to a production application, so deficiencies may not be exposed until you get a real-world workload going through it.

Technical debt is inevitable, but know what you’re getting into

Technical debt is unavoidable. Much like credit card points, using tech debt wisely can provide some advantages. Getting your product out the door quickly, and into customer hands as soon as possible is one advantage. Products like Heroku are great hosting platforms that can really speed up deployment time, but for added cost. Fortunately, it’s typical for these products to scale as you increase usage, so you can start out with very little cost. Just remember that as you grow, it may become cost prohibitive to use the most convenient solution, and you’ll have to move to a more technically difficult (but cheaper) option.

Another instance of debt (that will sneak up on you) is upgrading the stack whenever new versions are released. Young technologies are susceptible to many breaking changes between versions. An upgrade from v1.2 to v2.0 may be a huge jump, but in a few years v3.2 to v4.0 may not have so many large changes. The time taken to accommodate the intricacies during upgrades and maintenance can be considered debt that will be repaid sometime in the future. Doing regular maintenance and upgrades is a good idea, otherwise you’ll find yourself jumping from v1.2 -> v4.0, which is a huge endeavour, and no longer a routine task.

Consider the talent pool for future hires

Looking at GitHub’s “State of the Octoverse 2017”, here’s a very good graphic showing the programming languages people are using.

With this visual, it’s easy to see what the most popular languages people are using. JavaScript, Python, Java, Ruby, and PHP (paired along with their respective web frameworks) are in the top 5, but I don’t think it tells the whole story. JavaScript is fragmented into a lot of different fast-moving frameworks. PHP has a large following, and many sites are built on it (Wordpress!), but the sentiment towards the language hasn’t been positive recently. Personally, I think Ruby and Python are probably the best balance between popularity, developer friendliness, and future-viability. A language that is too new, old, or declining in popularity may not have enough talent available for future hires. In my experience, the developer-friendly and human-centric culture around Ruby bleeds into the developers themselves, which could make for hires that are a good culture-fit.

How do I make sure my engineering team can keep up with the times if they only work with tried and true technology?

Continuing education and technical conferences are a great way to keep up with modern technology. Encourage side projects and open-source work. Experimentation with new tech is great, as long as they are given the time to do it.

There is no recommended tech stack that fits every product. While when building your MVP, you should use whatever language what you know, to keep productivity high. In company with a more established core product, you can (and should) experiment with some new technology, given the chance. Just remember that the technology should be chosen because it is the best for the project at hand, not because it’s new and hip.

‍