For a software engineering team, choosing a programming language and its associated tools, apps and open source projects is a momentous decision.  A good decision can make your development more agile, accelerate your progress, and expand your technical capability, while a bad decision can lock you into a money-draining technological dead end. Here are six important considerations to take into account when selecting software languages and platforms.

Choosing What’s Best vs. What’s Familiar

The primary challenge any company faces when selecting a programming language or software platform is choosing between what’s best and what everyone knows. Software that is optimal from a technical viewpoint isn’t always best from a teamwork viewpoint. For example, the software your engineers prefer might not be compatible with an important app used by another department affected by your decision. Consider what options are feasible for your entire team before proceeding.(1) Make sure you get input from other departments besides Engineering and IT when choosing critical technology so that you can see how your tech decisions affect your whole company’s business objectives, recommends Puneet Shivam of Avendus Capital.(2)

Locating Available Talent

Another consideration when choosing software is the available talent pool. For instance, Scala and React.JS are two of today’s hottest emerging development languages, but experienced developers with this specialty can be hard to find.(3) Consider how hard it will be for you to find talent with the skill set you need when choosing languages, or plan to invest in training.

Evaluating Platform Support

Another factor to evaluate is the resources available for the technology you’re considering. A popular language tends to have a larger community with more support and tools to tap into. Today’s most popular languages are currently SQL, Java, Python, JavaScript, and C++.(4)

Evaluating Platform Maturity

Along with support, a platform’s maturity is a related factor to consider. Well-established languages have gone through more development and testing than newer languages, which means less bugs and more well tested APIs. For example, while the core modules of Node.js are stable, the npm registry contains many flawed and untested apps,(5) so many organizations are delaying adoption until the platform is more mature.

Considering Cross-platform Support and Portability

Another element to evaluate is cross-platform support and portability. Will your platform allow you to interact with apps that your company or customers run on other operating systems? Will you be able to pivot or make changes to your core platform as your business progresses and as technology trends change?  Is your language available on any Java Runtime Environment? Etc. Consider what other platforms and programs your app will need to support when choosing languages and platforms.

Estimating the Long-term Cost of Ownership

It’s also important to estimate the long-term cost of ownership when choosing a language or platform.  A platform like .Net is more expensive, but comes with extensive support and compatibility via Microsoft.  With unlicensed platforms you get more flexibility, perhaps, but you are implicitly taking on more support labor.

As tech writer Raj Sabhlok points out,(6) even open source software can come with hidden costs. For instance, if you’re using an open source tool to save money on app licensing, you should estimate how much it will cost you to develop the app instead of simply purchasing an existing app built on a premium platform. Maintenance and support are other costs to factor in. Additionally, you can get locked into an open source app just as you get locked into a vendor, leaving you responsible for troubleshooting, upgrading, security, and other tasks. Don’t neglect these factors when estimating software costs.

Next Steps

Once you’ve selected your platform, it’s time to start assembling your team. For a guide to building and managing a competitive, agile software engineering team, see our Building and Managing Competitive Software Teams series on the Telegraph Hill Software blog.(7)