"Software Maintenance" - two words that can cause incredible fear and anxiety among software developers. Questions arise like "How are we going to be able to maintain this and still work on our new projects?" or "What could possibly go wrong?" knowing full well that their production is not in its pristine form. Even the fear of hords of consumers relentlessly complaining that a particular feature is omitted, buggy, or just not working in the way that they personally would like to see it working constantly nags at the back of the software developers mind. "What if I make it worse?"
Believe it or not, these types of fears are really present in some software companies, especially those that are not very large and can handle hiring a team whose sole responsibility is to maintain the software that either they wrote themselves or another adjacent team had worked on. But with the recent boom in the number of programming languages designed for various purposes, the software industry is poised to encounter a problem that it had seen once before: a shortage of people who know a particular language and can maintain the software for it. This problem is compounded by the fact that there are pieces of larger software projects that are written in various languages. For instance, in a .NET solution, you can have DLL modules written in a number of .NET languages, where 1 DLL may be written in VB.NET, another in C#, and still another written in J#. In the non-.NET realm, developers may be faced with the challenges of maintaining code written using C, Java, Pascal, and many other compilable languages, all working together to satisfy a common goal.
Yesterday I was sitting in my Programming Languages class and I realized why companies have such a hard time maintaining legacy software: because most of the new programmers that end up having a degree are encouraged to use various programming languages to achieve certain goals when those particular languages are better suited for specific purposes. For example, businesses may write a big accounting program with a frontend in C/C++, but the calculation system (the backend) that provides the data may be written in FORTRAN. Though you can not insert FORTRAN code into a C/C++ compiler and vice versa, it is perfectly acceptable to create compiled modules from the two languages and use merge them together using an assembler. So, in a sense, as Computer Science students, we are encouraged in these classes to learn and use multiple languages together to achieve certain goals, and this is good and bad.
The good: Mixing languages has some advantages, mainly it is easier for the programmer to work with languages designed for specific purposes and exploit those advantages when a need for them exists within a project. For example, it is easier for a programmer to use RPG to generate reports than C++, but it is easier for the user to use C++ to provide high-level data processing routines and management than RPG. This leads to another advantage: quicker project development timelines. With increased ease-of-use for the programmer by utilizing certain language's advantages, they are able to code particular pieces of the project quicker, thus leading to a finished product faster and more cost-effectively. Another advantage, at least for the programmer who knows a specific language: job security. We see this all the time in the software industry as FORTRAN slowly begins to fade away, it is still used today only because of the fact that it may not be very cost-effective to try to translate huge FORTRAN projects into another more modern language, thus a particular programmer sees job security in being one of the few to both know the project intimately and also know how to maintain the program in the language it was written in.
The bad: Creating a hybrid program causes a lot of problems as well. Problem solving can be more difficult, since a technician examining the code for problems must be aware of all the components and understand the languages involved and how each language works and their overall effects of particular statements on other related modules. Also, as programmers of "legacy" languages retire, the intimate knowledge of those languages and the projects written with them retire with them, and so newer programmers who are hired to replace them may have a much more difficult time attaching themselves to the project, and thus cost businesses more as the time for learning increases. And finally, the crowning glory of problems, it simply confuses the hell out of the programmers. Nothing is worse than trying to understand what a particular piece of code is doing so that you can try to work with it or code around its limitations.