Rewrite of legacy code [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 6 years ago.

My department is currently faced with the responsibility for the task of maintaining a rather large COBOL code base. We are wondering how to add new features to keep up with business needs. COBOL programmers are hard to come by these days, and we also think we would get higher productivity from using a more modern language like Java or C#.

We feel that we have four options:

1. Rewrite everything from scratch, leaving the old application to itself until it is ready to be replaced
2. Rewrite everything from scratch, getting some people to maintain the old application to cope with new business needs as the new one is being built
3. Write all new functionality in a modern language and finding some way to integrate the new code with the old functionality.
4. Keep maintaining the old application.

What do you consider the best option for us, and why?

Answer 1

Migrate the application gradually?

Is there a way you can interface other code to the COBOL, and gradually rewrite components as changes bubble through? You may never get rid of all of it, but does it really matter?

Rewriting existing code is generally a bad idea. It will be very risky (e.g. risk breaking some poorly understood functionality someone is relying on) and use up a lot of time without achieving anything useful that is visible by most stakeholders.

Don't assume that a competent programmer won't be able to learn COBOL if the need arises- one programming language is much like another. If you hire someone competent at (say) C++ or Java, they'll be able to learn COBOL.

Answer 2

This is a variation of Option 3:

Microfocus provide a tool called Enterprise Server which allows COBOL to interact with web services.

If you have a COBOL program A and another COBOL program B and A calls B via the interface section, the tool allows you to expose B's interface section as a web service.

For program A, you then generate a client proxy and A can now call B via a web service.

Of course, because B now has a web service any other type of program (command line, Windows application, Java, ASP etc.) can now also call it.

Using this approach, you can "nibble away at the edges" to move the GUI to a modern, browser based approach using something like ASP while still utilising the COBOL business engine.

And once you have a decent set of web services, these can be used for any new development which provides a way of moving away from COBOL in the longer term.

Answer 3

Another solution could be:

Translate the code to a modern language of your choice.

Typically, that would involve several big chunks:

• Rewrite parts of the legacy app that cannot be translated. At least, use structured programming constructs everywhere.
• Implement a internal DSL that makes it easier to map constructs from the old language in the new language.
• Implement a throw-away source-code translator for 90% of the code.
• Translate the remaining 10% of tricky code by hand.
• Spend a lot of time getting the darn thing to compile.
• Get the whole thing through some serious testing and fixing.
• Slowly clean up the resulting animal to make it idiomatic.

The main advantage of this approach is that it will preserve all the nasty business corner cases have been encoded over the years in the code base. The big problem with from-scratch rewrites is that they discard all this accumulated knowledge.

Another advantage is that it turns an annoying problem (maintaining a cobol app) into a a fun problem (automated language translation), so you have a chance to get a good programmer engaged with the project.

Comment by Jim Denver

Won't it be very hard to write a translator that translate into code that is somewhat readable and maintainable? Our problem is that the COBOL app is a maintenence nightmare. We don't want this to become the same nightmare in another language.

I cannot tell how hard it will be. It is easier if the code you are starting from is regular. But in any case you will end up with "COBOL written in $LANG". This is just a starting point to incremental rewrites until the maintenance nightmare is fixed.

This is just an alternative to "rewrite from scratch" and "maintain in COBOL". It might just be that the value of the accumulated knowledge in the code base is less than the expected cost of an incremental cleanup.

Answer 4

I've done a migration of an old system to a new one myself (though it was on a much lower scale).

We quite successfully used the "gradual replace" (#2) approach, for a client/server system (a smallish, inhouse-written reporting system). We actually did it with a twist, by using a "proxying" approach:

• First we implemented a new server that offered all the functionality / call interface of the old server, but internally just delegated everything to the old server, which was kept running.
• Then all clients were switched over to the new system; this was relatively painless as the new system was essentially just a wrapper.
• Finally, we gradually rewrote the new server to implement functionality without calling back to the old system.

This approach gave a lot of flexibility, and allowed implementing new stuff without touching the old code. The changeover lasted over a year, and the last parts of the app were only migrated to the new system because the old server was running on dedicated, aging hardware that was to be decomissioned.

I actually went down to the server room to personally shut down the old server when everything was migrated. That was fun :-).

Incidentially, this "gradual changeover" approach also allowed us to implement some logging in the new system, to decide which functionality was used how often. That way, some of the old server functionality could be scrapped, because it turned out clients no longer used it. That was a significant advantage of the "proxying" approach.

Answer 5

admiteddly, the problem involves cobol which makes any answer specific to your needs, if you said "we have an old VB app" or old C app, then option #3 is always the right way to go.

I've worked at 3 companies who decided to go for option #2. 2 went bust trying to pay for the new system whilst only gaining revenue from the old, the 3rd came very close indeed.

The other factor to opetion #3 is that you get to keep all the old bugfixes you've doen over the years. Every rewrite always introduces more and more bugs, partly because you'll want to get the rewrite done quickly, partly because you'll be writing it in a new, unfamiliar language, and partly because all new code has bugs.

Refactor and replace logical chunks of the old app, eventually you'll have a nice shiny new one. Start with the GUI to get the safest approach to the new. Besides, by the time you've finished rewriting the app in something new, something even newer will be the coolest and your new app will be obsolete and you'll be posting the same question all over again!