How do you continue to develope large (long term) software systems with legacy and new code?

Question

I work on a large code base with a large install base of users. The code was originally written in vb6 with a few c++ COM modules for low level work.

It is completely infeasible to rewrite all of the code that is already written in vb6 and is being used by our customers every day, but we are also continuing to make improvements and customizations to the software (large and small).

My solution so far is to write most of the new code in c# (winforms and even wpf now) and then use COM interop to call the modules from vb6.

Does anyone out there have experience with long term software suites like this (10+ years) that can't be stopped for a complete rewrite, but need continual new development at the same time. Also, in mixed systems like this, what is the best way to interface the modules? I am using COM right now, but have considered IPC with separate processes as well.

Answer 1

I think you need to look at your upgrade paths for your customers. The fact is that at some point when they have 16 core CPUs you're going to want concurrency to speed things up. So you have a business case to move away form VB6 and towards WCF. WCF has built in concurrency and synchronization support. It can be used for local in-proc communication as well as cross-process and cross-machine communication. It also has the benefit of allowing you to do more AOP style programming.

Answer 2

I think you have a good plan. This will eventually move most of the code into C#, taking advantage of the better toolset.

Does the VB6 code comprise COM objects?

You mentioned that the code "can't be stopped for a complete rewrite". But you don't have to stop. One by one, you can replace each piece of VB6 functionality with the equivalent C# code. This would allow you to make one change at a time (preferably with automated tests to prove you haven't broken anything).

Answer 3

It's hard to give a single all encompassing answer but the high level approach is clear. At least, this is the approach I've used. Prioritize your goals and then try to identify the costs of reaching those goals. Your costs will essentially boil down to 'developer time'.

First, you want whatever is working to keep working. If you have something that is working, and there is no good reason to rewrite it, keep it.

If some of your existing code needs updating to do its job, then you are looking at maintenance costs. At this point you need to determine if a rewrite will improve maintenance costs enough to be worth it. Don't forget to subtract testing and debugging of new bugs because there will be new bugs. Don't dismiss working code just because it is old.

If your existing code is sufficiently modular, you can usually chip away at it one piece at a time. Rewrite the high maintenance components first.

If you will be doing new development in C# then you should be fine working with COM components until you have enough justification to replace them.

Answer 4

Re-write on a needs basis when there is a motivating factor.

One old Windows project I worked on had a rules engine written in C that was working so we just left it as a black box DLL.

We built a new front-end and the user base was were impressed by the easy to use new modern look of the application. Nothing in the internals had really changed.

The database access layer was using SQL Server DBLIB and was not re-wrtten until we upgraded SQL Server.

Answer 5

I'm currently one of several developers working on a large legacy system that started out as a combination of C and C++ with Win32 and, later, MFC with a smattering of assembly amongst the back end C code. We've recently jumped from VC++ 6 to Visual Studio 2005 (and have since upgraded to 2008) for the latest version of the project that we're working on. Since the IDE/compiler upgrade, we've been cleaning up some of the look and feel and have been adding managed C++ with WinForms and now C# with WCF.

While the underpinnings of our system, including the back end, will almost definitely remain in C (at least for the foreseeable future), anything new in the front end will most likely be done in C#/WCF. When we have the time and/or need, we intend to start replacing older parts of the front end with equivalent C#/WCF code.

Answer 6

We have several systems of this sort. The disturbing part of all this is the lifecycle support status of VB6. There is a risk (however small) that you won't be able to get help from Microsoft with a showstopper issue with e.g. a future server upgrade, and won't have the ability to fix it yourself (say, due to incompatibilities between the VB6 DLL's and the patched server O/S). This is a risk your management might be interested in -- but then, if you don't have any support agreements now, perhaps they are comfortable with that?

We're actually looking at rewriting and redesigning a few of the more critical ones. We've tried incremental evolution, and it can work, but makes for an (let us say) interesting operations and maintenance situation. I'd strongly recommend instrumenting everything (old and new code) with plenty of configurable logging, if you aren't already, to help with fault isolation.

COM sounds like a reasonable interface between legacy and new. Unless you have very simple interactions between components, I can't really see why you would like to move back to a more basic IPC mechanism. COM has its complexities, but it also provides a lot of useful abstractions for e.g. data typing and versioning that you'd have to reinvent and maintain...