Dealing with multiple programming languages is usually a sign of progress – maybe you’ve bought another company and you have a whole new amazing product line to go with all the stuff you’ve done forever! Or, maybe you’re taking a look at your diverse company that’s grown over time and you see you have a rich and varied array of highly tailored infrastructure that you’ve built over the years. Whatever the reason, you may find that the in-house technology is as rich and diverse as the company itself.
Seems good, right? Variety is the spice of life! Besides, devs always say it’s a great idea to use the best tool for the job, and hey, it seems like everyone separately did that—and came up with completely different solutions. While variety can make for exciting vacations and might even work well for individual dev teams, it isn’t so great for your organization as a whole. Maintaining systems in significantly different languages presents critical challenges: Developers may not be able to move from project to project even if company priorities change, hiring requirements may become almost impossible to meet, and critical information might become siloed, causing significant inter-system inefficiencies. These risks adds up to some very serious problems—but you can take action to prevent them. Rewriting your system in a single language will improve your ability to maintain and scale going forward.
Problems with maintaining multiple languages
1. Siloed teams
Having a multi-language environment makes it REALLY hard to move team members from one team to another. If one team writes in PHP and another writes in C#, what happens if the C#-based project needs to ramp up quickly? Moving people over from the PHP project to the C# project would require months of training, costing significant time and money. Realistically, it’s just not an option for a project with a shorter timeline. This can be particularly frustrating in a case where the PHP project has an idle developer or two.
2. Bad bus factor
Having a multi-language environment means that you may have a really small bus factor for critical part of your system, even if you have a large IT staff. The situation might be even worse when a critical project is in maintenance mode, and that project was written in a programming language that most of your existing developers don’t know. That means that the team of developers who are not only familiar with the project, but *capable of quickly ramping up* becomes a large risk. Should those core maintenance people move on, you could end up with a project that noone else is able to hop into quickly. Your critical component might become dependent on your small maintenance crew, and it’s very hard to justify growing it when there’s not really more active work to do.
3. Efficiency blockers
Without a common understanding of your system landscape, inter-system problems or inefficiencies could lurk for years. A multi-language environment might mean that you’re much less likely to have individuals who understand the system landscape as a whole. When company systems are created with common tools, it’s easier for developers to move from one project to another, and to help each other out. In a company with a healthy culture, this will likely happen naturally,and when the language across projects are the same, you should expect a lot of this movement and sharing. The cross-system understanding developers will get from this behavior is extremely valuable. It will help them reduce duplication and repetitions in the system, to understand why certain processes are done a certain way, and more quickly find inter-system issues.
4. Hiring challenges
A multi-language environment might mean that you’re asking for the near-impossible in hiring. You might find yourself trying to bring on someone who has a really unusual combination of skills. On the other hand, you may find yourself trying to put a square peg in a round hole by asking people to support software that they’re really not equipped to, which is exhausting and makes them that much more likely to leave. Hiring organizations might make proficiency in several of the company-dependent languages a requirement: which presents another challenge: It’s difficult enough to find good developers when you’re just focusing on one language. Seeking those proficient in your particular combination of languages might lessen the problems above, but it’s going to make your hiring/replacement problem much, MUCH more difficult.
Case in point: we had a client who had a development staff of more than 20 people, however, a critical product was entirely supported by just two. These developers were completely overloaded, with a months-long backlog. The problem was that the rest of the staff worked on the company’s many C# applications, but this single product was entirely LAMP stack (mysql, perl, etc). The LAMP developers didn’t know any C#, and the other developers wouldn’t have known where to start with perl. As a result, nobody could help anyone else, and should one of those two LAMP developers leave, there will be no way to support this critical product. Of course, this state of things wasn’t planned: the parent company bought out a partner and brought its products (including this LAMP-based product) in-house. It was great to have synergies! However, over time, the company realized that they just couldn’t properly support this critical product and had to make a change.
Rewriting for your future
A rewrite IS a big task to take on, and, and it’s not usually the first tool to reach for: if there’s a smaller alternative, it’s well worth considering. If you rewrite everything cleanly and perfectly, you can still end up with the same problems you started with. Unfortunately, in the case of a multi-language environment, the language itself is a large part of the overall problem, and a key part of the risk. There are no smaller tweaks to correct the root issue-only a rewrite is going to fix it. Even something that is “unfortunately about the same” post-rewrite will be in a much better place since the language-diversity risk will be much improved.
Why do it?
Consolidating languages has many benefits for both development teams and the business. Developers can focus on their core skills, and don’t have to worry about trying to do a good job trying to support something they don’t really understand. Companies are much more able to manage “bus factor” risk when developers can be more easily moved from project to project, allowing staff to fill in on other projects. Finally, it should be at least somewhat easier to attract talent if you’re looking for expertise in a smaller set of skills. The people who can develop at a highly-skilled level in the set of languages you happen to be using is going to be smaller and more expensive the more unusual your requirements. Make your staffing requirements a bit more vanilla, and you’re more likely to be able to find the people you need!
What language do you choose?
So if you have a bunch of languages, which one do you hinge on for the rewrite? If you’re already using C#, this is a solid choice for consolidation, and it has many traits you would want regardless of the language-though many other languages, such as Python or Java also fit most or all of these criteria. You want a well-respected language with good tooling. Being a multi-platform language is also a big plus-being able to run on any system (Windows, Mac, Linux, whatever) is extremely valuable for projects that might live a long life or might later be distributed widely. You want a language that is either supported by companies that will be around in 20 years, or has strong, organized community backing. Finally, you want to choose a language that is fairly popular – this is another factor for longevity, and makes it much easier to hire developers.
How to rewrite right
Of course, this kind of rewrite has to be done VERY VERY carefully: Part of the risk of a multi-language rewrite is that, by nature, it’s very difficult to refactor/gradually migrate to where you want to be. So planning out something that’s not an insane big-bang deploy takes a lot of thought and cleverness. For our client in the example above, we ended up finding places in the existing code where we could break up processes: For instance, before and after writing critical data to a file or calling into a database. We replaced pieces of the process one chunk at a time, then tested and deployed them one at a time (with several weeks in-between each piece). This way, we all easily understood the scope of what we were validating, and the amount that could go wrong in each deploy was small.
Language diversity is often a product of company growth, but that same growth can lead to complexity that makes your application much more difficult to maintain. Consider reducing language diversity by focusing on a smaller subset of languages and obsoleting the rest. A great place to start with this kind of effort is a thorough assessment of problems you actually have, and of those with are those that most urgently need correcting. In the long term, focusing your technologies should lead to a more flexible, agile team, allow more focused hiring, and reduce overall maintenance risk.