如何避免在迁移到.Net时从头开始重写VB6

Question

in our company we develop and sell a VB6 application and we think it's about time to migrate it to .Net.

The main reasons are:

• We expect VB6 runtime support to end at some point in time, and we do not want to start the migration just then since it's probably gonna be a lengthy process.
• There is just 1 1/2 VB6 developers left. The half one being me.
• More and more customers asking for features like cloud and mobile device support.

I know that rewriting an application from scratch is the least recommended way for migrating to .Net. I totally aggree with that! Throwing away over a decade of code feels just wrong and would be such a waste of money spent, that I have a hard time recommending and justifying it towards our management.

But right now I don't see another way to do it.

Let me tell you a little bit about the application:

Like I said it has been developed for over a decade. There have been numerous developers working on it, most of them rather unexperienced at that time. We have one developer left from the initial team. That application has been his first and biggest software project and by now he realizes that many of the archtectural decisions made over last 15 years have been horrobly wrong, others were right at that time but have not been refactored to meet changes made in other parts of the application and so have become wrong at some point in time. This application seems to be a showcase example of code rot.

We are talking about an application of about 150 KSLOC, all in one single executable. It uses about 15 external DLLs, some of them third party ActiveX controls, some of them are our own .Net assemblies.

Adding new features to the application is still possible and being done, but takes ages compared to our other .Net applications. The reason is that every little change in the codebase requires changes all over the place. The only reason why changes are possible at all is because that one developer simply knows most the dependencies and quirks of the application. As you might have guessed the rate of unexpected side effects and bugs is quite high.

My first thought about migrating that application was to first clean up and refactor, then migrate/convert possibly using tools from Artinsoft/Microsoft/WhoEver and then refactor again to get a nice and clean .Net application.

But I see some problems:

1. There seems to be no way of refactoring the old application. There is no automated testing whatsoever, not even a formal method for manual testing. Every little change requires manual testing by experienced users who just know where defects might hide.
   • on the other hand I have established a process and set of tools for testing of our .Net applications which gives us a solid base for making refactorings
2. Converting that code to .Net without major refacting feels like: Garbage in, garbage out. Eventhough I hate calling the old application garbage because somehow it works and has proven itself useful.
3. Our management has a habit of explicitely demanding quick and dirty solutions, disregarding the effects it has on the productivity and against all recommendations from the development team which has at some point started to deny the existence of quick and dirty solutions in order to be able to do things right. That does not mean that we polish features, but we do include the time to write tests and do refactoring in our estimates. So knowing this, I suspect that once the code is converted to .Net and fixed to the point where the application starts and seems to work, the refactoring-phase will be canceld and the application will be shipped to some customers.

So. What I think is that, despite the fact that rewriting from scratch will take a lot of time and resources, it might still be our only option.

Am I missing an option? Do you see possibilities of not having to rewrite that application?

Answer 1

I suggest that you take a step back and read this paper by Brian Foote & Joseph Yoder (University of Illinois). It provides some architectural insight into the problem you have and options to solve it. It's titled 'Big Ball of Mud' (please don't laugh, it is a serious paper). Here is the abstract:

While much attention has been focused on high-level software architectural patterns, what is, in effect, the de-facto standard software architecture is seldom discussed. This paper examines the most frequently deployed architecture: the BIG BALL OF MUD. A BIG BALL OF MUD is a casually, even haphazardly, structured system. Its organization, if one can call it that, is dictated more by expediency than design. Yet, its enduring popularity cannot merely be indicative of a general disregard for architecture.

These patterns explore the forces that encourage the emergence of a BIG BALL OF MUD, and the undeniable effectiveness of this approach to software architecture. In order to become so popular, it must be doing something right. If more high-minded architectural approaches are to compete, we must understand what the forces that lead to a BIG BALL OF MUD are, and examine alternative ways to resolve them.

A number of additional patterns emerge out of the BIG BALL OF MUD. We discuss them in turn. Two principal questions underlie these patterns: Why are so many existing systems architecturally undistinguished, and what can we do to improve them?

BTW, I think your best option is to use the current application as your Requirements and rewrite everything in VB.NET or C# using a proper design.

Answer 2

There are four main options when you have an application like this:

• Do nothing: this is always an option, as everybody knows, if it ain't broke don't fix it. However this might not be an option for several reasons such as needing to comply with some security requirements at the company, or simply because one of the components doesn't work in new platforms.
• Rewrite: This would be the dream, right? being able to get rid of all the bad practices and duplicated code and so on? Well, it might be that way, however you have to think all the risks involved in developing a new application from scratch. Do you have all the formal requirements? what about test cases? do your team know every little detail in the code or would you need to go line by line trying to figure out how why that if is there? Also, how many bugs do
• Buy something off-the-shelf: Since you are an ISV this won't be an option.
• Migrate: Of course you'll be bound by the programming practices you used for the original development but you'll get to a new platform faster, all your business logic will be automatically migrated, you can actually hire developers for the new platform and you can get rid of the legacy elements. From here you can also take advantage of all the tools available to refactor code, continuous integration, unit testing, etc.

Also, with an automatic migration you can actually go further than just WinForms. There are also tools that can take your C# code all the way to the web using a modern architecture.

Of course, I work for Mobilize.Net (previously Artinsoft) and this is my biased perspective. We've been working on this for around 15 years and have seen dozens of clients who come to us after trying to re-write their application and fail after months or even years of struggling without being able to deliver a working application.