Advice about migrating software to new language

Question

We have a program that is about 15 years old and on version 6. It is in a niche market and used by very small departments in very large companies all over the world. It works in a very highly regulated environment and has been heavily influenced over the years by the customer needs making it almost like a bespoke system.

One of the main problems is that this program orignally started off on DOS and has migrated through pascal to Delphi and Windows. The whole thing has become a bit of a clunky nightmare with goodness knows how many styles of programming in place, although it does work.

It is basically a windows form driven system with an Oracle database backend, most of the code is mixed in with the UI and it doesn't really follow an OO design. Just to give you an idea of size, we're talking about 1.3 million lines of code spread over hundreds of units and a database with about 150 tables. So it's not a small package.

There has been talk about migrating into a new programming language (most of us here like c#) and basically reorganising, cleaning up and adding all those new features people want along the way. Possibly a new database? possibly using a web type architecture?

Does anyone have any experience and/or advice when it comes to doing this kind of thing. Obviously we're going to have to try and convince management why we want to do a re-write. My biggest worry is that after 2 years work they end up with exactly what they have now that is much more maintanable and pretty but no more sellable.

Answer 1

You pretty much nailed it there.

As long as the old system is sustainable and you don't get any clear benefig of rewriting it, there is no point in rewriting it.

If you can work on the current codebase to implement changes, you're fine. If your current codebase is at a point where no changes can be made without breaking the whole app. You may consider a rewrite.

You could also just stick with your current app and try to refactor the code to be more maintainable. That can be done easier (no need for 2 years of development), and it will save you money in the future.

Answer 2

If you chose to do a rewrite, try and have someone on the team that developed the original version - that way, you'll be slightly less likely to make the same mistakes they did first time around.

Don't just rewrite for the sake of it. It will inevitably take longer and pose more challenges than you think it will now - be prepared to back up your decision to rewrite with sound arguments - ideally based around increased profit via lower maintenance costs and improved feature set.

Mind you, do people actually pay substantially more for more features..?

Don't rewrite unless absolutely necessary.

Also see Things You Should Never Do, Part I

Answer 3

I haven't done such a thing, but the literature is full with documentation of failed projects. So I would advise against a complete rewrite. Rather, redesign parts of it that are particularly bad, and make sure you have always a working application.

Answer 4

Hmmm. There's a mention of this by Joel here, where he basically says, "don't do it." He makes for a convincing argument.

Answer 5

I believe a more compelling reason for a rewrite is found in the software architecture:

Is your legacy code able to support:

• the current work-load ?
• the evolutions needed in the business-logic side of your application ?

If one of those two parameters (or both) are evolving, a rewrite is a viable path to follow.

What you will need to avoid is:

• any kind of 'big-bang' effect where you replace abruptly your former system by the new one (so parallel runs must be in place, to insure at least an iso-functional status - the common features must work the same way)
• any 'tunnel' effect where you ask your legacy system to not evolve one bit during the 2-3 years of rewrite: you need to manage the coherency between the evolutions of the legacy and the new features developed.

Answer 6

Before rewriting the software, you should read the following article:

http://www.joelonsoftware.com/articles/fog0000000069.html

Rewriting may not be the best idea. Instead, you may want to slowly and organically refactor and improve the old code, perhaps introducing a new language for new features and slowly refactoring the most important and most frequently changing old features into the new language. You'll never get the code to the ideal state, but over time, you can make the code much better. Realistically, if you rewrite everything, you'll never get the code to the ideal state either.

Of course, another huge goal of your organic, slow refactoring of the code should be to build up a library of unit tests. All new features and bug fixes should have unit tests built up for them. And, you should slowly begin building up unit tests for the most important and poorest quality older features. Building up these unit tests may drive some of your refactoring so that you can properly isolate features for testing.

Answer 7

The important thing to remember is that this is a business not a technical decision so you should be asking questions like:

• How much is this going to cost?
• Are there cost benefits in migrating it? I'm a strong believer in software entropy so if you are making a lot of custom modifications it'll be easier and cheaper doing this on a new code base than an old one. This is hard to quantify however.
• Will it bring in new business?
• What is the future of the platform you are migrating to? Consider that Java on the desktop is in a poor state compared to .Net (WinForms/WPF) (imho). Sun is in a precarious position. Microsoft isn't.

When working out how long it will take, you need to identify where those lines of code are and what they do. How much is UI? How much is database? How much is other layers? If theres lots of library code perhaps you can start by converting DLLs to C# using them in your existing codebase. If this is a software suite thats divided into multiple applications (eg a user app and an admin app) then you could convert the smaller or the lower risk of the two. This'll allow you to assess risk, build infrastructure and build team skills and experience.

Ultimately, if the move won't make you money or save you money theres no justification for doing it. If the risks are too high then you shouldn't do it.

As for Oracle, theres no reason to change unless you're on a really old version for some reason (eg using a deprecated feature like character mode in Oracle 6 or Forms, which will only be officially supported out til 2011).

Answer 8

In my experience, rewriting is almost always the correct answer when you have a monster like you describe. I was once part of a project that had been written over about a year by a team of 15 developers. It was a nightmare codebase (most of the developers were incompetent). When they moved some of us new folks in, 3 of us decided to rewrite it. We had our ground-up rewrite fully functional in 4 days with more features than the original. We also chopped the number of lines of code to about 1/3 of the original size. The new code made sense, it was easy to modify, and it ran faster. Of course, this wasn't a business decision; it was all volunteer work (both the original development and the rewrite).

Another project I worked on that I was getting paid for went through a similar process after I left. The code was pretty bad (poorly designed, poorly maintained, plus it was JSP on Tomcat) and very large. We started to implement some refactorings and good design practices and it got a lot better. It still had a lot of dark corners no one understood though, and the manager of the project always liked the latest and greatest (he probably had ADHD, which may explain how the original codebase got so bad), so right after I stopped working there he had the entire thing rewritten in Ruby on Rails. Word is that they finished it in a few months (the codebase was about 7 years old) and it's nearly as functional as the original (unnecessary features cut).

I think the reason most rewrites fail, especially in the corporate world, is that no one is willing to cut the developers that caused the problem in the first place. If you take people who hack features into existing code and give them free reign to create a new app, you'll end up with a giant hack. You need a SMALL team of developers (I'd say ideally 3, no more than 6) who really knows the requirements. They also need to really understand good design practices. Then let them loose.