Translation Technology Myth Busters
Convert or Rewrite?
Many migration teams that we talk to believe that it is not possible for a translation tool to produce useful output; they believe that nothing can be salvaged from their legacy software assets; and they believe that they will just have to rewrite their applications from scratch. However, after talking with us and seeing what our technology can do, they change their minds. They appreciate that their working production code can be extremely helpful to their migration effort.
The following sections present some common opinions about software translation and how our Tool-Assisted Rewrite approach is changing minds and giving people a sensible means to migrate huge legacy applications.
Teams that understand translation tools and invest in using them effectively are able to do more re-engineering than teams that don't. Leveraging migration tools frees up resources so a team can spend more time on analysis and redesign and also facilitates experimentation with different design options and ultimately enables an efficient, systematic implementation of a new design across the target codebase.
We believe the answer to the question: "To port or rewrite?" is "Balance!". We specialize in a hybrid approach that we call the Tool-Assisted Rewrite. In a nutshell this is an iterative methodology that involves two closely related activities:
- defining where *you* need to be in terms of the new platform architecture and
- implementing an efficient conversion process to take you there.
By leveraging our flexible, powerful translation tools to help transform your existing VB6/ASP software assets into correct .NET code you will minimize the total cost of conversion *and* be able to enjoy lower total cost of ownership once your codebase is in .NET.
A proper tool-assisted re-write balances the economics of manual development with automated conversion. It reduces cost and risk, and produces an architecture that takes advantage of new components and best practices of the target platform, rather than one prescribed by a single tool vendor and inextricably constrained to the legacy design.
We just have to rewrite it
Rewriting some of the application makes sense and our translator is designed to take advantage of this. You can configure our translator to integrate translated code and hand-written code automatically. In addition, the real work of a rewrite is in designing the new architecture standards and coding patterns not typing them in and our translator can be configured to automate radical transformations and then apply them correctly across an entire codebase. Our flexibility means you get the best of both worlds: the quality of a custom rewrite delivered with the efficiency and accuracy of an automated tool.
The code produced by the translator will be 'junk'
Look at the translation, find the 'junk' and decide how you would make it better. You can then reconfigure the translator to meet your specifications and give you an improved translations. You may repeat this process until all "junk" is removed. If there is something you cannot do 100%, you can probably get very close so you can finish it more efficiently than trying to rewrite it all by hand.
Only a person can do it
What exactly will the person do? What is 'it'? Can refactoring tools help with some of those tasks? How can you best balance the work that a person should do with the tasks that a translator should do? How can you do this more efficiently and still preserve quality?
The legacy code was designed for the old platform. It is worthless
The legacy code meets the business requirements of your customers; and it describes what your program does in detail. Since you must preserve the functionality of the application, the majority of the code will be semantically similar, even on in the new platform. The source code will do the same functions; it will just describe those functions in a different way.
The legacy code lacks the detail to describe the new system
What additional information is needed to describe the new system? You will have to specify that information even if you plan to do it by hand. By putting this additional information into a form that the translator can use, you can have the translator do most of the work. For example, if one describes how to replace legacy COM APIs with .NET classes, the translator will make those replacements for you.
It cannot be done
"What is 'It'? What are the specific things that the translator cannot do? Why do you think the translator cannot do them?" Bear in mind that your system is processed by a "translator" every time you do a build: it is translated from source code into machine code by a type of translator called a compiler. Our translator works very much like a compiler, the difference being it emits source code instead of machine code, and it is extremely configurable so that the format and content of the source code can be customized to your requirements. The problem of computer language translation is a difficult one, and this fact is underlined by the many translation tools that are inflexible or do a poor job. Great Migrations tools are different:
The tools have matured over almost thirty years of research and refinement in the science of computer language translation.
- The tools use a semantic approach that handles complex restructuring much better than a syntax-driven approach.
- The tools are flexible and can be tuned to meet different source and target code requirements.
- The tools are designed to work with large codebases that have many separate components.
- The tools enable an agile methodology that refines and balances automated translation with manual work.
It is too much work to figure out how to restructure the old code to new code
Yes it will be a lot of work, but it is a natural means of formulating a design to take advantage the new platform. In addition, using tools to help you leverage the legacy code and implement the new design will free up resources for design. If you do not use the legacy application as a reference, you will essentially be building a brand new application. This is known to be a very expensive and time-consuming process -- particularly if you intend to reproduce a huge application that has evolved over many years of accumulated development.
Leveraging your legacy code can eliminate the disruption, effort, and risk inherent in trying to regather a vast set of functional requirements that has accumulated over years of development. They key to successfully upgrading a huge legacy codebase is to leverage the code for what it is: an extremely detailed, production-tested specification. Doing that efficiently takes flexible, industrial-strength translation technology and that is what we have to offer.
