Spice Up Legacy Code Leftovers

What to consume tonight? You dig around your server and don’t find much. You think maybe it’s time to create something new or buy a pre-made 3rd party application. But wait… at the back of the server you find an old application. A compiled application that you really like and is still consumable but does not taste as good as it used to. It is also starting to smell a bit funky, like an old pair of legacy socks.

You could consume the application as is but would really like to freshen it up so it tastes better. You are also worried that consuming it as it might upset your delicate system and cause you to throw an exception or worse, a massive core dump.

You could create a more palatable version if you could find the source code. You dig around the server and success! Tucked in the bottom rack you find the source code just sitting in a folder. The problem is that is all you find. No documentation. No source code control. Nothing else. Just the application running in production and the source code.

Putting the source code on the counter you walk over to your shelf with all the cookbooks. Where is it… that old recipe book your grandparents gave you. Ah-ha! You pull out the Legacy Code Cookbook. This should have the recipe you need.

Legacy Code Leftover Casserole

A recipe to freshen up an old compiled application. Assumes you can only find the source code, database, and nothing else.

Ingredients

• Compiled application with database running in production.
• Source code for the application.

Tools you will need

• Version control (e.g. Git, GitHub, Mercurial, BitBucket, GitLab, SVN, etc)
• IDE appropriate for the application. (e.g. VS code, Intellij, etc)
• Local or remote test DB that matches production. (e.g. if production is running Postgres 8 you should run the same locally or in test)
• Containers (not required but makes life easier). (e.g. Docker)
• Staging environment that matches production as closely as possible. (e.g. if the production environment server is running Ubuntu 16.04 so should staging)

Steps

1. Add the source code to version control including any assets (e.g. images) used by the application. If available also add database files such as schemas and/or migrations. While most files should be added to version control some break this rule such as environment config files (e.g. files with passwords and environment specific values), log files, and files generated by the application (e.g. report files).
2. Create a backup of the production database. This is also a good time to set up scheduled production backups and a data retention plan. The frequency of the backups will depend on how costly losing data is. For example, if losing a day’s worth of data will not have a significant impact on your business then daily backups are fine. The data retention plan should follow local laws and regulations for your given country and/or industry.
3. Examine The existing code at a high level and look for any indication that source code you have does not match production. For example, the application in production has a screen or report that you don’t notice source code for. If you find a major discrepancies then you should try to find a more recent copy of the source code. If that does not exist then you need to use a different recipe then this one as the rest of this recipe assumes you don’t find any major discrepancies.
4. Restore a backup that is accessible to your development environment, which will be setup in the next step, but is also secure as the backup contains production data. If you want to restore the database on your local laptop, or other in-secure location, the data should be anonymized first. Where you restore the database should also follow any local privacy laws and standards.
5. Get the source code to compile and run. This will likely be the longest and hardest step as you figure out all the dependencies the application needs. The easiest way to do this is to create a development environment in a container (e.g. Docker container) or virtual machine that matches your production environment as closely as possible. Any config settings will need to be updated for your development environment. Hopefully they aren’t hard coded in the application, if they are then you will have to extract them to .env or similar file.
6. Run the application and see if anything obvious is broken. Specifically focus on the critical paths of the application. For example, if it’s an e-commerce application can customers make purchases?
7. Get the automated tests to run and pass, assuming there are any automated tests. Worst case scenario you can ignore failing tests but only as a last resort.
8. Run the application and this time explore the entire application and make sure everything works. If possible, compare it to the production version. Fix any issues you find and also add some tests. You might have to mock out or set up development accounts for 3rd party services.
9. Create a staging environment and, if possible, use infrastructure as a code tool (e.g. Terraform, Ansible, etc) to create the staging environment.
10. Install the application in staging. A good time to document and/or automate the install process.
11. Test the application on the staging environment. Ideally you have non-developers doing some testing at this stage, if possible.
12. Switch the staging environment to production. How you do this will depend on your application. Monitor for issues and address them as they arise. You likely missed something but now you are in a good position to make fixes, do a staging release for testing, and then push to production.

Now that you can recreate the original application from scratch you can modify as needed. Freshen it up. Remove dead parts that smell bad. Enhance it with new flavors. Basically make the application more palatable for yourself, and others that consume it.