If you have more than one coder on your team, chances are you have standardised on a programming language. Whether it’s C, Java or Python, people need to be able to read and write each other’s code to do their work. The language was probably picked by some of the first coders in your team, or was based on an analysis of what was needed at the time.
As time passes, however, you’ll find that more and more of the initial reasons for the language choice will disappear. Perhaps the language expert left five years ago and you have created a new framework that better matches your needs. Eventually, you will have to find out whether the language you are using is still the best one for your needs. Looking at it 15 years later, should your website still be written in C?
You don’t have to change a programming languages in one go; different systems can handle different parts of a web application, for example. It’s also quite likely that there are bridging libraries that allow you to call from one language to another. The boundaries between some languages can also be blurred when you consider things such as Jython and Clojure.
Making the decision to change programming languages will never be an easy one. You must answer some hard questions: Will the effort of retraining be worth in the advantages in productivity? Are there enough trained developers with the new skills you require in your area?
One problem to watch out for is the creation of a large chunk of legacy code that nobody quite understands anymore. As staff members come and go, less people will remember the old code base and it will become hard to fix bugs. This knowledge loss may well have happened anyway; a change of programming language only draws a clear line in the sand showing where the difficulties start.
If you decide to rewrite some of your legacy code with the new programming language, you will have some new opportunities. You can use what you’ve learnt over the years to avoid some of the same design mistakes. And you can sometimes use the rewrite to provide new functionality. Unfortunately, you will also probably introduce new bugs. This is where a strong test suite can be very useful.
There are some side advantages to changing your programming language. It provides staff with an opportunity to learn more and discover new skills. It lets you revisit old discussions where the assumptions no longer hold. And you can use the change to improve things for the better. Remember, however, that changing the programming language won’t fix inherent issues, such as bad programming skills.
