Refactoring: Marketing Spin Detected
We live in the age of marketing spin. Sometimes it seems that nothing means what the plain words say. For example, we hear people say, “Can you refactor my COBOL to Java?” To a technically knowledgeable person in the IT industry, that is the same kind of question as “Can you pedal my fish faster than 20 miles per hour?” As the late Jim Morrison might have said, “You CANNOT refactor your COBOL to Java!”
But you can translate it to Java. And vendors who say “We will refactor your COBOL to Java” either don’t know what refactoring is, or they are deliberately trying to avoid saying “translate” or “convert” because those terms bring to mind JOBOL and transliterated code that still looks like COBOL and is not maintainable code. They also don’t want you to know that their translated code comes with a secret, proprietary runtime API that you have to pay a 6-figure license fee for, every year. By the way… if you bought one of those solutions, and would like to get rid of that runtime, we can do that for you! Just contact us here: Let’s talk!
What is Translation or Conversion?
It is possible to translate statements from one programming language to another. This is done on a line-by-line basis, using a grammar that defines the programming language (just like English grammar defines the English language). When translation is applied to whole programs or whole systems, it is a conversion of the program or system from one language to another, but the structure and organization of the old language remain. “A translator or programming language processor is a computer program for specifying a program in one programming language (the target language) that is functionally equivalent to that (a translation of another) in a different language (the source language). This is without losing the functional or logical structure of the original program.” – https://en.wikipedia.org/wiki/Translator_(computing)
Translation can be done well, or done poorly. We partner with the firms that have the best translation solutions, and sometimes that approach is appropriate for a customer’s needs. Just don’t call it “refactoring” unless you actually DO refactor meaningfully, with object oriented code and not just some small re-arrangements to “check the box” for refactoring.
What is Refactoring?
Refactoring: Unlike translation, refactoring changes the structure of a program without changing the programming language, to improve it. If all the programs in a system are refactored, then the system can be said to be refactored. Line by line translation of computer code (such as COBOL to Java) does not accomplish any kind of meaningful refactoring: the new Java code has the same fundamental structure as the COBOL and many in industry call it “JOBOL” for this reason. The key point here is that refactoring is done within a set of computer programs to improve their structure while keeping the existing programming language in which the programs are written. “When a software system is successful, there is always a need to keep enhancing it, to fix problems and add new features. After all, it’s called software for a reason! But the nature of a code-base makes a big difference on how easy it is to make these changes. Often enhancements are applied on top of each other in a manner that makes it increasingly harder to make changes. Over time new work slows to a crawl. To combat this change, it’s important to refactor code so that added enhancements don’t lead to unnecessary complexity.” – https://refactoring.com
What is Modernization?
Modernization: to move an existing software system onto a new computer and operating system while improving every part of it to incorporate modern structure, standards and programming languages. Sometimes, within a general discussion of modernization, this full modernization is called re-engineering the application: “Re-engineering: A technique to rebuild legacy applications in a new technology or platform, with same or enhanced functionality – usually by adopting Service Oriented Architecture (SOA). This is the most efficient and agile way of transforming legacy applications.” – https://en.wikipedia.org/wiki/Software_modernization
The ResQSoft Approach
Our approach here is a full modernization through re-engineering with automated tools and reusable, proven code. We don’t need to refactor what we produce because our code is already refactored — it is fresh, properly structured code that has zero need of refactoring. We can prove this by running CAST on our code, and we normally run CAST on every iteration baseline delivery to demonstrate without a doubt that the code you receive from us is high quality code. To the best of our knowledge, the vast majority of solutions in the “transformation” industry involve line-by-line translation and COBOL emulation with a proprietary vendor API. It does not cost more, or take longer, to get a much better, maintainable body of source code for your application. And we can make enhancements as we go because our tools were built for new development — not just modernization.
If you think you have received high quality code, because your vendor’s lobbyist assured you it was so, run CAST or failing that, just run the McCabe Complexity metric on that code. There’s a number of free tools to do this, such as CCCC. Single digit complexity numbers are good, numbers over 20 should raise a concern — but do measure, even if you disagree with what is a good and bad number. If you have doubts, run the same measurement on some known GOOD code and you will definitely see the difference.
We re-engineer your language(s) — all of them. Give us a call or email! Or, contact us here.