02 May 2008

Sean's Universal Theory of Business Software Maintenance

"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.
I discuss these points here because I too have had the opportunity to have to deal with the points listed above. In the projects I have worked with at work, we have software written in various languages: C, C++, RPG, C-le, Java, JavaScript, and even database languages like SQL, and recently, HQL. However dissimilar they all may be, they all serve an ultimate purpose in our projects, but we have run into issues trying to understand what certain components do over others. The ultimate end result? Appreciation of a particular language's usefulness in the computer software industry, but an ultimate frustration at the limitations of understanding and use of a particular language against another. So in short, though I hold to the belief that nearly everything can be written with C++, I understand that nearly doesn't apply to all of it, and therefore there are pieces that just can't be written with C++ efficiently and thus other components must be used. Java is one of those languages that can be used as an example. Great for most small, non-time-critical softwares, but when interfacing with the operating system or some other hardware component, JNI must be used and components then must be written and compiled in another language. Oh well, maybe as time goes on, computer scientists and business software scientists will come together and develop the ulimate programming language that encompasses all the advantages of many different programs. I just hope that it looks like C++ and doesn't have a steep learning curve. But then again, once that language is released, there will always be something else out there that will try to one-up it. Alas, this is the ulimate problem of being a software developer - there will always be a better language for what you are doing, whether now or later.

1 comment:

AJ said...

This is why I think a classical Computer Science education is crucial. Unlike specialized technical schools, a solid classical CS education teaches you over arching general ideas and concepts that span whatever language. It also teaches you how to think and tackle new concepts -- especially in an industry such as computing where things are evolving exponentially. It really gives student the opportunity to learn whatever flavor of the month because they have a solid grounding in concepts in CS. Learning new languages just becomes a matter of learning syntax.