Tip Sheet: When to Rewrite?

A look at when to rewrite your VB6 apps in VB.NET

A common question is, "When should I update a working, deployed, VB6 app to VB.NET?" The answer, in part, depends on how well the VB6 app is doing its job and if it is showing warning signs that indicate that it is nearing the end of its lifecycle. In this article, I'll cover some of these warning signs.

First of all, don't upgrade simply for the sake of upgrading. If the app is doing its job and working well there is no need to change it until outside factors require it. For example, one doctor I went to 2001 was using a custom DOS program written in Clipper that he had commissioned in the late 1980's! It worked for his practice and he saw no need to change until regulation changes force him to do so. But, what if your application isn't such a smooth operation?

Many VB6 programs, over time, get what I call the Winchester House effect. In case you didn't know, the Winchester House was built by the widow of inventor of the Winchester rifle. To avoid hauntings a medium told her about, she kept the house under construction for 38 years and this resulted in a sprawling mansion that had many features that made no sense. Like this house, many VB6 programs have been added to and added to over the years until they become monsters with 100's of forms and modules, some of which no longer make any sense.

When a program gets in this state you'll begin to see "fatal improvements". That's what happens when a small change in one part of the program causes failures in other parts of the program. If a single line of code is changed and this causes indeterminable erratic behavior by the program, you've got a problem with that program. If you find yourself telling other programmers to avoid making changes in troublesome modules, this is a warning sign that your application's quality is degrading.

Another sure sign of program quality degradation happens when new developers are brought onto your team or when you have to discuss the program with people outside your team. If you have to describe a myriad of special conditions and circumstances that a newcomer must be careful about, this is a sign of impending disaster. If you find that you can't adaquately and concisely describe what the program is supposed to do in certain modules to an outsider, that's a problem. If you find that you can't give a tester or a code reviewer the information they need to adaquately do their job, this is yet another of impending failure.

Another sign of trouble is if you can't rollback your releases easily. If the program has become so complex that returning to a previous release is just as troublesome as deploying a new release, that's means it's time for a change. Even worse, if no one really knows how to get back to the previous production release, this is a very serious problem.

So, if you see the quality of your VB6 application degrading in this way, it is prime time for undertaking a redesign using VB.NET. In later articles, I'll cover some techniques for extracting a VB6 program's design and ways to implement a gradual update if your program isn't already on its last legs. 

   Save to del.icio.us

Published on Sunday, May 27, 2007   |   © 1999-2007 J. Frank Carr, All Rights Reserved