Over the past couple of months I have had the opportunity to meet with many people at the DevReach, PDC and DevConnections conferences. It has been a whirlwind of activity, but in a good way. Through my discussions I was not surprised to hear that several organizations still have production applications that are not leveraging .NET or are still .NET 1.1. Most recently, I spoke with a couple of developers who have a six (6) year old rich client application written in Visual Basic 6.
Legacy applications like this are a tough call for most businesses because many are integral to their daily operations. The conversation was refreshing because it has been a while since I have thought about all the difficulties associated with legacy applications. My introduction to .NET was migrating a 12 year old solution while the existing application had to be maintained with a small group of Visual Basic developers. Here are a few things to consider that might help anyone in a similar situation.
Which language to choose, Visual Basic .NET or C#?
Honestly, I don't get into the arguments on which language is better. I personally prefer the C# syntax, but have no problem with Visual Basic. If you have a team that only knows Visual Basic, it does not make sense to make your project more complex by having them learn a new language in the process. If you are going to use Visual Basic, I do have two recommendations.
- Set OptionStrict = On, why is this still not a default in Visual Studio 2008?
- Remove the Imported namespace "Microsoft.VisualBasic"
Do we maintain the current application in parallel?
You might not have a choice, but more than likely you will have to keep working on the current application if there are business needs. You really should setup some timelines and freezes to minimize the impact on the new solution.
- Design phase - Legacy application maintenance will probably remain business as usual.
- Early development phase - At the very least have a limited freeze, only vital changes will be made to legacy application. Document everything so it gets into the new version.
- Mid-development phase - Beg on your knees, for a complete freeze. Hey that rhymed. Anything new will be in the initial release of the new application. You have to have time to get everything in sync so don't wait too late for this.
Rewrite in .NET means Re-design?
It is recommended that any move to .NET from something like Visual Basic is a rewrite, but that does not necessarily mean redesign. Start with the foundation of your application. This will probably be your database architecture, depending on the application. There is no reason to redesign your database if it does not need to be overhauled. With the solution I mentioned above we were moving a Microsoft Access and Oracle back end to SQL Server, so we had to redesign everything. Minimize the design changes to what is absolutely necessary.
Don't trust the old code?
This can be an unexpected challenge if the application has been around a long time. That means years of modifications and lazy developers leaving useless code, don't tell me it doesn't happen I have been there. You have to mirror existing functionality, but the logic may be flawed. Testing of the new application in conjunction with the legacy application is paramount to the success or failure of the venture. Mirror what the application does and don't trust the old logic to be correct. Test, test, test.
No change for the sake of change
One more quick thing to mention, don't get pulled into the feature creep trap. Know what you are going to do before you make a decision to change something. In the application I mentioned above, we kept saying that "No change for the sake of change". It will be tempting, but only change those things that really need to be fixed or made easier. That means user interface, business logic, etc... There will be instances where change is needed, but think about the impact on the user and the code when doing anything.
Before I get hate mail, there is obviously more to it than this, but I am addressing specific points from conversations. There are many important points to consider so if you have something to add, please do so.
