Whenever you launch a new software project, one of the first questions that comes up is what technical stack to use. In other words, you’re asking, “What programming languages and frameworks will be involved?”

Many companies have a go-to stack that they always use. That’s fine, and doing so can have strategic advantages. However, before diving straight in, it’s a good idea to have a checklist that helps you think through your choices.

Here’s a quick list that can help you do that.

1. Investigate the Problem Domain

What specific problems will your new software solve, and what are the highest value functionalities that you intend to develop? How do the various languages you are looking at match up in those areas?

Developers get into online battles all of the time about what the best programming language is. This is a useless discussion. No such thing exists.

However, some languages have unique strengths that cause them to outshine the others in specific domains.

For example, if you need to do serious data analytics or machine learning, you will almost definitely want to use Python. It has massive developer adoption and incredible statistical libraries.

If you need to support large numbers of real-time connections, you can consider something like Elixir which can handle hundreds of thousands or millions of connections on a small server.

2. Consider Your Team’s Skills

If you have a team that has deep knowhow with Java and not much else, it might not be worth venturing outside of that territory unless you need something super specific.

If you have a situation that forces you outside of your normal box, consider isolating the less familiar parts behind service layers.

For example, suppose you are building an analytics dashboard of some kind that needs Python, but your team is mostly familiar with Ruby. You could set up a single Python service that handles the statistical aspects, and use Ruby for the rest of the application.

This helps you minimize the impact of not being as familiar with that particular language.

3. Look at the Cutting Edge

It’s a good idea to do some digging into what the newest tools are. Often times – but not always – people who develop new tools will find ways to make the actual software development work more efficient. Additionally, new tools often have serious performance gains.

It’s worth looking into these things because your team being more productive is a real competitive advantage, and your code being more performant is good for your products.

You don’t always need to latch onto the latest, greatest thing. But I do think it’s useful to keep an eye on what’s out there.

4. Evaluate the Scope

Take a look at how big the thing you are about to build is. Is it a giant application? Is it a microservice? Is it a giant application made up of microservices?

What’s the cost of messing it up?

If you have a team that’s eager to try a new language, and they are building a small service that will be finished in 2 to 4 weeks, it might be worth just going for it.

On the other hand, larger scale projects obviously require more consideration. This can be a good reason to use services in your architecture. It gives you a natural place to quickly test new languages, tools, and frameworks.

Need Help?

We are a full service software engineering firm. We can help you with everything from design to project management to development.

Got a project you’d like to talk about? Get in touch at info@centralstandard.tech.