How to Choose A Development Language
Whether you’ve got a technical co-founder or you’re hiring an outside firm for developing your product, one of the first decisions you’ll have to make is what language(s) your product will be built in. Sometimes these decisions are made for you, as is the case for any of the mobile platforms. However, if your product has a server component, the options are many.
How should the business choose?
Read that last sentence again. Notice that I said what the business should choose, not necessarily what the people doing the work would choose. The criteria below are, in my experience, the most important to consider as you make your choice. They are in no particular order, and all are geared toward preserving flexibility as you move forward.
I’m purposely not addressing the technical benefits of each language, so as to not get into a religious debate.
Availability of Talent
How available are developers to either add to your team or to replace the team you’re currently using? This seems like a simple question because, for the most part, there are developers for any language at the right price. But what you’ll find is that if you’re not using one of the more common “modern” languages, developers will turn up their noses. “Java, do people actually use that language anymore?”
Of course, just like fashion, language trends change over time, and what was once old can become new again, and what is new will go out of fashion. You need to assume that you’ll be hiring new people for your team at the most critical times in your company, and you need to assume that those people will be hard to find. Don’t make it more difficult by choosing some obscure language that no one’s ever heard of.
A great test for this is to look at the language-specific meetups in your area. Go to three or four of them for the language you’re picking. If the room is full and there’s a lot of energy, great sign. If there are five people there and the snacks are stale, run away as fast as you can.
Open Architecture
This is a loaded topic because there are varying definitions of “open.” For our purposes, I define open as (preferably) open source, runs on open-source operating systems, and where there is a rich, vibrant community working to make the language better. Great examples would include PHP, NodeJS and Ruby, as well as Java (though certainly less so now that Oracle is in control of the primary build). Microsoft’s .NET platform is moving toward open, but is still heavily reliant on the Windows operating system.
Ease of Deployment
Can you deploy the application on any of the major hosting platforms? Amazon, Heroku, Digital Ocean and others generally specialize in languages that are open-source, such as Ruby, NodeJS, PHP and even Java. If you’re choosing Microsoft’s .NET Framework, there should be a particular reason you’re choosing it, such as the need to deploy on Windows machines or similar. Sometimes this is a requirement for government environments, but it’s rare these days. If you have particular requirements like HIPAA compliance, you have to ensure that your underlying service provider is compliant and, ideally, can help you get to compliance more quickly.
As a business, you want the ability to move your application, as needed, to new environments to take advantage of either features such as better scaling or for costs reasons. If you box yourself in with your technology choice, you limit the options down the road. Since the future is completely unknown, preserving choice is a must.
Security and Privacy
Every modern language provides mechanisms for securing and encrypting data. However, there are some that provide much deeper and richer capabilities either due to it being an area of focus for the language or the amount of time they’ve been around. For example, Java is heavily used in applications where cryptography is a core component. It’s just better at that task (for now) than, say, NodeJS. The key thing here is that, as a business owner, you must understand exactly what level of sophistication you need to provide for the business, and then ensure that the choice of language aligns with your requirements. This is a deep topic, one I’ll explore in the future.
What About Scaling?
Everyone loves to prattle on about the ability of one language over another to scale. Blah blah blah. The fact of the matter is that almost every language provides you with the capability to scale. Facebook is built primarily on PHP. Netflix is built primarily on Java. AirBnb is built primarily on Ruby. Would you be Ok with your product being as big as any of those?
If you have people on your team who know what they are doing, scaling the application will work, albeit with some amount of pain almost assuredly. Nearly every product has bodies buried from early bad decisions. It’s just the nature of an ever-changing landscape. Don’t sweat it. If you’ve got defined targets in place for users or volume, ensure that your development team is testing for those levels and make them show you the results. Then move on with your life.
Wrap Up
Choosing the language(s) for your product is like picking the right neighborhood to live. You know there are going to be some neighbors you don’t like. You know there are going to be things you didn’t think about before you moved in. But if you’re generally in a good location, chances are your decision will work out. And, just like moving out of your house, it’s expensive to change languages and will cost you more than you plan.
Just remember:
- Language choice among developers is a religious topic. Your job is to cut through the religion and make them defend their choice with facts.
- Every language has inherent benefits and drawbacks. You don’t need to understand all of them, but do your own research and ask people you trust (like me)
- Preserving maximum flexibility for your product and availability of people to join your team is critical to long-term success
Your Assignment
Attend a local meetup for PHP, Ruby or NodeJS developers. Hang around and just ask questions, and make note of the size of the gathering and energy in the room.
- Are most of the developers working at other startups?
- How full is the meeting?
- Is the topic engaging and interesting, and is the discussion lively?
Next month, do the same thing for a different language to get the feel of possible differences in the community in your area.