What Will You Generate?

When a new, green field software development project gets started a multitude of technology related choices can or need to be made.

On what platform(s) will the application run?

What will be the UI technology? What will be the (relational) database?

What version control will we use for the project?

And what issue tracking system?

Can the version management and ticketing system be integrated to further improve productivity?

How do we get continuous building and integration up and running?

Probably one of the favorite topics (and often leading to lengthy debates) among developers and development managers is that of the target programming language, and this for a wide variety of reasons. Generally speaking all developers have a favorite language. It may be the first language they learned, the language that made them really understand OO programming, it may be the new hot and exciting programming language of the moment.

Choosing the target programing language

When planning a legacy migration project (from e.g. Natural, COBOL, IDMS, VB6, or Delphi), a slightly different set of choices needs to be made.
Choices such as, will the application move away from Mainframe altogether, and run on Windows or *Nix? How do I replace my TP monitor?  What is the best replacement for my JCL scripts? Can I preserve my Job Scheduler?  What database will I use?

The target programming language definitely is a topic in this context get asked as well, where currently we see the majority of requests for OO languages such as Java and C# - on condition that the project targets Windows or *Nix. When the target platform remains Mainframe, then COBOL seems to have become the de facto standard for (business) programming language for migration projects. But, over the last couple of years I have come to realize, that the target language is in fact secondary to how you answer the question: “In what style shall we generate the code?”.

For example, when migrating from Natural to an OO language (Java or C#) we should consider who will perform the maintenance of the migrated application, once it is live. If this will be a completely new team of .NET developers then you would want to see different output code to be generated when compared to the case where the application will be maintained by the original Natural development team that migrates with the application.

The Natural dilemma

The answer to this question will have a significant impact on the effort required to perform future application maintenance, and therefore I consider this question to be not only relevant, but to be more important than the choice of the language itself. This holds certainly true for a language such as Natural which is in fact a 4GL with a very powerful runtime that has a lot complex and implicit behavior (e.g. event and escape handling).

This behavior may be logical to a person who has worked with Natural for many years and he/she would like to see that reflected in the new system as well, but to the majority of developers who have never developed in Natural or even heard about it, these concepts are completely alien.

These developers are helped with making the implicit behavior (more) explicit instead. Of course, there are always cases where this is less or even not relevant. The obvious example of this is where the application sees hardly any functional updates anymore. Returning to the case of Natural applications, I have seen multiple cases of this over the last years. In such a case, the style nor the language are really relevant in the scope of the project.

This frees up time for other important questions such as how to best test (or proof) that the migrated application is functionally identical to the original application. But that is a topic for another article.

Oh, and in case you are wondering, my favorite programming languages are Java and Python.