Week 11 – refactoring: the new language of modernization

When you hear the word “refactor”, what is the first thing that comes to your mind? In the context of modernization, it is often used to describe how we will “translate” the code (typically from Assembler or Cobol) into a more modern language like Java or C#.

Code translation is an extremely effective alternative in our toolkit to modernize code. The first question that I will attempt to answer is why do we need to modernize the code? If you still have it and it is running, why do we need to mess with it?

Perhaps the number reason people utilize code translation tools is to free it from proprietary, legacy hardware. This begs the question: can you not take the code as it is and run it in a different hardware environment? This is a very interesting possibility which we will explore in a subsequent post in #themodernizationdesk. In the meantime, what I will say is that this is not always a possibility and when it is, we need to consider other factors which complicate matters. Sometimes it might be a feasible alternative, but until we discuss all options and their tradeoffs, I would stay away from this one. If nothing else because nothing is truly free and executing the code which was designed to run on a mainframe environment in a distributed environment with an x86 processor requires code interpretation or a different compiler.

For the moment, let us assume that if we want to separate the code from its existing running environment, it will either need to be rewritten or translated. Given that we have already explored the amount of work it would take to rewrite the code using the extracted Business Rules, we are looking for an alternative to minimize the manual work to continue our focus in delivering additional functionality for the business.

Following this logic, we are left with refactoring as the only viable alternative to run the code in a different environment?without having to re-write it. As such, it becomes an attractive proposition for those who are trying to minimize the hands-on-keyboard labor and testing effort required to provide functionally equivalent code in a lower cost, distributed x86 environment.

The second reason which might influence an organization to use refactoring is talent and skillset. There was already a deficit of Cobol and Assembler developers a couple of decades back. As new languages and frameworks continued to be introduced with ever increasing functionality out of box, the effort required to learn legacy languages increases exponentially without a clear payback or career path which has increased the skill gap. This has led most of the junior developers to favor the new programming languages over the legacy ones.?

In this regard, having converted the code from Assembler or Cobol to Java will open the number of qualified developers who can maintain it and use it as the foundation to create additional new features.??

The third reason that many developers would use refactor is to leverage modern APIs more efficiently, while the latest version of Cobol can technically call REST APIs, performance is not necessarily optimal and will necessarily require changes to the application to avoid creating lengthy response times.?

As good as it is, language translation is not without its potential drawbacks, just ask anybody who has tried to use a translator application as their only way to communicate in a foreign country. Code translation is no different, you will need to understand the areas where the automated tool will not give what you are expecting and proactively address them.

It is also important to notice that the automated tool will translate the code as it is today and will not fix any of the existing bugs in the system. From a maintenance perspective, there are two major models used during transition where the automated tool will maintain linkage. E.g., During transition, any bug fixing, new feature development will be still performed in Cobol and automatically transferred to the modern language by the automated refactoring tool. After the transition is complete (or before if needed), the linkage is broken, and the new code is maintained in Java going forward.

There are multiple tools in the market which perform code translation and it is a method that can facilitate and accelerate the migration out of a proprietary legacy hardware environment, giving you access to new talent pools and allowing you to use modern APIs more effectively, but yes, there is some work involved in making sure all nuances are translated correctly and that the code performs at functional parity. E.g., Most of the manual effort when doing code translation is on the testing itself.

Finally, it is the recommendation of this author that if you start the journey for automated code refactoring you come up with a plan to complete the migration as planned.??The most vulnerable state of modernization would be in-between the states where some of the code runs on one environment and some in the other. This would require the effort to keep both code and data in synch, which over time will be non-trivial and create a babel tower within the organization.?