Things move fast in the software development world. Technologies come and go faster than in most other industries. Programming languages tend to stay a little longer, but at a certain point in time, you might find yourself with a legacy programming language. How can you recognize this, and how should you react?
What Is a Programming Language?
Software is developed by writing code in a language that humans can understand. This code is then translated into instructions that the computer can understand.
Like “normal” languages (e.g. English or French), a programming language evolves and has a community that uses it. These communities can shrink and grow, can be active or calm.
This puts certain languages at an advantage over others, depending on what needs to be developed. There are general-purpose languages that can be used to solve all kinds of problems (like C# and Java). But there are also languages that work best for specific problems, like R.
What Is a Legacy Programming Language?
Programming languages often start small and then gain traction over time. This means that more and more organizations use the language and/or produce software with that language. These pieces of software can be applications for end-users, but also libraries that other developers can use or educational resources like books, video’s and conferences.
All this together forms a community. These communities can thrive, but they can also wither: developers flock to another community and software products are no longer actively maintained. Sometimes even the programming language itself is no longer being maintained or supported.
This is when you could start considering a programming language a legacy programming language.
What Are the Risks?
If your organization users a legacy programming language, you are exposed to some risks.
Security
Legacy programming languages have the risk of losing support for security updates. As I’ve mentioned, the programming language has to be translated to something the machine understands. This is called compilation. If the compilation leads to a possible security issue, a vibrant community will create a fix. But if the programming language is no longer supported, your product will remain exposed to this vulnerability.
The same applies to any libraries that your software product is using. Maybe your code is safe, but a library you’re using isn’t. If the library is no longer supported, your product is also at risk.
Increasing Cost of Development
When your developers are working with a language, libraries and tools that can be considered legacy, they will have an increasingly hard time implementing the requested features. In a vibrant community, there are (open source) libraries to implement certain features. These libraries make the work of your team significantly more easy, and reduces the time for them to finish the feature (because a lot of the work has already been done).
But if your developers can no longer find such libraries, they will have to implement these libraries themselves, costing you money.
Shrinking Talent Pool
Legacy programming languages tend to be less popular among developers. There are always exceptions, but in general, you will find it increasingly difficult to find the talent you need. And what talent you find, may not be interested in switching jobs. This too can increase the cost of development, if you need to pay these people more to retain them.
Lack of Support
No longer being supported can mean several things:
- the programming language no longer works on modern hardware
- there are no more updates to the language
- it is increasingly hard to find educational materials out there for your developers
In either case, continuing development in the language becomes harder and more costly.
What Can You Do?
There are several aspects to this question. First, are you stuck with a legacy programming language? Or will you be in the near future? Even though I explained what a legacy programming language is and the risks that come with it, you might still have good reason to keep working with the language.
Should You Change Your Language?
For example, banks are known to still have servers running COBOL applications. They have rationally assessed all risks and decided to only convert to newer languages at a very slow and careful pace, if at all.
But most companies are looking to migrate even business-critical pieces of software to newer platforms because of the aforementioned risks.
How Can You Change?
If you’ve established that you want to get rid of the old programming language, there’s a world of opportunities and challenges ahead of you. Your plan of action will depend on several factors. Some that come to mind are:
- are there legal considerations that rule out certain languages?
- are there technical reasons to prefer one platform over the other?
- what is the skill set of the current team?
- will they need training?
- what is the cost involved with different platforms?
- how easily can you find new talent in your region?
Choosing A Language
In general, I would say it’s safe to bet on one of the bigger players like C# or Java. Depending on your industry, it might be strategic to choose a more “niche” language like Python (popular in data engineering) or C/C++ (if performance is critical).
Training
Next, you’ll need some training for existing employees. Both in a classroom to get them started and on the job. A temporary external consultant can be useful for training employees on the job. The employees often have a lot of knowledge about the domain, the existing application and any integrations with other applications. The consultant often has a good technical experience. Put the two together and they can both learn from each other, while porting your application to the newer language.
The Work
When you start writing the existing application in the new language, make sure everyone is on board and knows what the plan is. Are you peeling away layers and integrating the old application with the new as you go? Or will you be writing a new application that runs along the old one until you’re ready to switch? Also take time to critically evaluate if everything in the old application is still necessary. Less code to move over means cheaper and less chances for bugs.
Don’t Be Afraid
Having a legacy programming language doesn’t have to be a disaster. But if left as-is, it could become a strategical disadvantage overtime. Or even worse, a security risk. Identifying your situation and planning your exit strategy is important for your business.