Standing on the Shoulders of Giants
Chances are if you’ve been tasked with working on a legacy software application it’s because that application is still being utilized within the day to day operations of a business and has proven its value over time, otherwise it would have been cast aside a long time ago. It doesn’t matter if it’s an application that is used once a month by someone in the accounting department when they need to reconcile payroll or if it’s a customer facing application that sits within the businesses revenue stream, the application has undoubtedly become a part of the organization that the business has come to rely on.
This is in no small part due to the original authors of the application. They built an application that meet the needs of the business and continues to the deliver the goods and they did it all without the latest and greatest IDE tool sets.
Software developers, just like anyone else, can become so reliant on the modern conveniences that exist within their latest tool sets that when tasked with working on a legacy application, they feel like they were transported back to ancient Egypt and given the job of building the pyramids using only a plumb-bob to accurately measure the slope of the walls, instead of being able to rely on a modern laser level.
A good example of this is the process of debugging an application. If the application was written in Java or C# we could easily rely on the modern conveniences of an IDE such as Visual Studio or Eclipse that allow us to setup break points to see what the values of the variables are at a certain point in real time, and even modify the values! Unfortunately, we don’t have these luxuries when working with a legacy application that was written in an interpreted dynamic language such as Perl. But we can achieve the same result of monitoring the variable values using print statements, such as printing out the variable values to the error log.
This is the exact situation that I found myself in when I was tasked with porting a legacy website that was built using PHP and Perl CGI scripts around the turn of the millennium. It was being hosted on a Solaris Sun virtual machine using Apache as the web server, both of which were of comparable vintage to the application, and was given the end goal of moving it over to a CentOS 7 virtual machine running the latest version of Apache. This might sound straightforward enough on the face of it, just a simple lift process to move the code from one virtual machine to the other with small modifications around any interaction with the underlying operating system such as the path to the bin folder. Unfortunately, things were not that straightforward as it turned out. The landscape for the supporting technologies had changed since the website was initially developed with the introduction of several breaking changes between major version updates to Apache and its associated Perl modules.
One of the problems we ran into was finding documentation around the legacy Perl modules that were being used to run the website. The website relied on two SOAP web services and these web services weren’t being hosted within Apache but were making use of a Perl module called SOAP::Lite. A quick search on Google lead me to the module page on CPan, but not much else other than that besides some defunct links to http://www.soaplite.com. So, I headed over to the WaybackMachine and, lo and behold, it had scraped http://www.soaplite.com in the past and I was able to use it to look up some additional documentation on the module to get the SOAP web services up and running. While admittedly I had a bit of luck on my side that the site had actually been scraped while it was active, the WaybackMachine is still a good place to look if the website you’re looking for no longer exists.
The next hurdle we needed to cross after learning how to stand up the SOAP web services was to deal with the breaking changes that were introduced since the website had initially been developed. The first set of changes had to do with Apache itself, but these were actually quite easy since when you try to start Apache with a deprecated configuration setting it will fail to start and will alert you of the offending line. Dealing with the Perl modules proved to be the more difficult part, as not only were there breaking changes between older and newer versions of the Perl modules, but the package names had also changed. After locating the new modules that we needed for the latest version of Apache, we started working on the problem of the breaking changes that had introduced logical errors. Since we didn’t have an IDE to use to monitor the values of the variables, we relied on print debugging to print out statements to the error log, not only to display the values of the variables but to trace the execution and progress of the Perl scripts.
Working with legacy software can at times feel cumbersome and repetitive due to a lack of tools such as Visual Studio or Eclipse that automate a lot of the tasks associated with development. However if we understand the basic concepts we can achieve the same end results, just be prepared to spend a little more time getting there.