How many types of coding languages can you name today? 15? 20? And these are just the ones that spring to mind, the household names. When I first got into IT over 20 years ago, there were just a few actively used programming languages, but there are dozens now. While new ways to express creativity are almost always a good thing ? and the growing number of new programming languages certainly is a testament to that end ? the current volume of languages out there may hinder IT stability in my opinion.
I remember working on a project the nature of which dictated using C++. C++ wasn't just the best language for the job; it was the only language suitable for the job, given the interfacing APIs and other factors. The problem was I was the only developer in our IT department who knew C++. On the one hand, my knowledge was great because as a "team," we were able to provide a solution to the business unit we supported. On the other hand, no one else on our team could support the solution, and after I left that company, no one in-house could extend it, and the company was not about to hire a C++ developer to support a single solution.
The standard tooling for that particular business required the skillset of a C++ developer; however, today most IT projects themselves do not require or mandate a specific language. While every programming language has its strength and weaknesses along with its accompanying best and worst use cases, organizations nowadays are free to pick from an assortment of languages that are nearly equal in producing the desired outcome. The challenge is to pick languages that are sustainable by the development community as a whole as well as by your personnel.
The problem today is programming languages have become almost like fashion trends - here today and gone tomorrow. Several months ago, I was visiting with IT management at a company, and they said they are struggling to hire development talent that knows the programming language they used to build a solution just five years ago. The company was facing the realization that they may have to rewrite the solution. This situation is not unique and can create a significant drag on IT productivity. The business unit will never understand why a working solution has to be rebuilt ? you can't blame them. Your end users only see the finished product and don't see nor care about the difference between a .NET or JEE version of the same app, for example.
Rewriting an app, as opposed to modernizing, reengineering or refactoring, is like reinventing the wheel ? it is wasted effort. There is no measurable improvement, enhancement or differentiation. When selecting a language for a project, IT needs to answer the following questions.
What is our current coding language standard? Sticking with a standard increases the stability and longevity of your apps.
Is the programming language of choice sustainable or is it trending downward into obscurity? This question should also be applied to the language currently within your standard.
Do your developers (yes, plural) know the language of choice? Unless you need to modernize, refactor, or re-engineer your app, you need to ensure you have an internal staff capable of writing and supporting the new app.
How is your language's historical usage numbers on several indexes? Considering the historical sustainability of a programming language can insulate you from selecting a short-term trendy language that will quickly cycle out of popularity.
What are the biases and personal interests of your developers who are making a language recommendation? Developers have a financial incentive to grow their experience over the course of their careers. What might be good for their resume may not be appropriate your company.
In the end, when it comes to enterprise IT, selecting a programming language isn't as complicated as determining a good stock to buy. However, thoughtful consideration and bit of due diligence will keep the productivity and agility of your organization hitting on all cylinders.
