Is this the "one in ten" time to rewrite?

Question

I'm very much against rewriting an application if it can be avoided. I understand the rule that 9 times out of 10, it's better to refactor, but I'm in a situation where it might be the one time in ten, and I'm looking to find that line.

The current situation is:

• I took over the maintenance of a VB6/SQL application.
• The total lines of code is 75-100k (code-behinds, modules, and classes).
• The original developer left, so it's just me, and there's no opportunity to expand the team, at least for a few years.
• There was no architecture to the program (just straight SQL calls in plain text in the form code-behinds).
• Doesn't try to follow the DRY or OAOO principles.
• Database had some primary keys, but no foreign keys.
• Before this system was in place, everything was managed in big spreadsheets, so this system really is a huge improvement over what they had, but doesn't do what they're envisioning.
• I was able to write myself some tools to replace all literal instances of table names and column names with constants and look-ups, and I wrote a quick code gen script to generate those constants and look-ups from the database, so now I can safely make database changes and see everywhere that broke. I have started normalizing the database "around the edges", but it's like 3% of the way there.
• There are no unit tests, so every time I change the database, I basically have to rewrite whatever logic sits on top of it, and I use the two versions to compare functionality and make sure it's the same. So far so good.
• I started by just trying to fix critical bugs to stop the bleeding, and I can safely say that's mostly done, so now I'm stepping back for a moment to look at the big picture.
• Management is supportive and reasonable in their expectations.
• The long-term goal is to convert it to .NET anyway...

So, I'm weighing these options:

1. Continue normalizing the database and modifying the VB6 app as I go (ends up being a piece by piece rewrite)
2. Put the VB6 one into a maintenance-only state (no new features), pick one functional module at a time and rewrite that part in .NET on top of a normalized database structure.

My thought is that if I choose option 1, then at the end I just have a VB6 app that they still want to upgrade to .NET, and I've looked into that and it's costly and time consuming, and even with the tools you'll still get something that's somewhat of a Frankenstein. If I go with option 2, I believe I can be done sooner, and I'll jump right to the target technology.

In the small scale pieces that I've already rewritten during my normalization process, the result has been an improved module over what was already there, so there is value being added during the rewrite.

The existing app, for all its flaws, is a great talking point for discussion. The people using it can tell me what's working for them and what isn't, so there's certainly a lot of value there that way.

So, does this qualify as one of those "one in ten" times, or not?

Answer 1

I had a project that was originally written in VB6 and they hired me to convert it to .NET. I recently left that job. I'm fairly convinced that the program probably shouldn't have been rewritten.

Here's some factors to consider if you take the re-write approach (based on my project)

• It will not be a straight rewrite. Once word gets out its getting re-written new feature requests will pop up and there will be a fair amount of redesign/re-architecting
• People will not accept the "maintenance-only" mode with out a lot of resistance first. For a while, every bug will be "mission critical"
• Porting a VB6 app to .Net should NOT be viewed as easier than porting a C++ app to .Net, or a Haskell project to .Net. There is some commonality, but in the end, it's a 99% different code base (possible 1% for existing equations)
• Assuming this program is in production (even internally) your new program will very likely not measure up, at least initially. You'll hear "But in the old way..." or "It used to..."
• Assuming your customers are not other IT people, they WILL NOT understand:
  • What is taking so long
  • Why it isn't just like the program (in look & feel) of the old one
• While the current app was developed over time, it will likely be expected that your app will have 100% of the functionality on go-live, and in less time.

Those are all experiences from a real life migration from VB6 to .Net. I was the only .Net developer. There was no resources to hire additional help. The main differences between my situation and yours is 1. the original developer was still there - just in a new role (making it harder at times) and 2. The original app didn't need a lot of bug fixes.

I think if I had it to do all over again, I would try to create some .NET dlls and incorporate those in the VB6 app. Piece by piece converting to .net. So perhaps you move the data and business logic for Accounts Receivable to .NET. All the other aspects stay the same. The GUI, the other features etc. Then after that's rolled out and marked as complete, take on the Shipping section and do the same thing. The final step is to create a new .NET GUI that uses your DLLs.

This gives you a couple benefits

• In the end the application is written in .NET
• Allows you to slowly roll out your changes. You won't be debugging shipping and accounts receivable and hr etc all at the same time the week of "go-live"
• Allows you to use more modern tools without wrecking the whole program. Want to use NHibernate, PLINQ or MEF? Do it one module at a time. Learn the tool and make small steps
• Allows for flexibility on the GUI. In the end, you could do WinForms, WPF or a Web project, all utilizing your core DLLs.
• Doesn't throw a ton of changes at the user all at once. You've re-written that accounts receivable portion and the user has no clue, because the GUI is the same. Then when you roll out the GUI, you KNOW that your backend is working.
• Will make future refactoring easier. You've already broken down your project into bite-size chunks. You can further work on them knowing what they effect etc.

I would be VERY weary of deciding as a single developer to re-write this application and deliver them a working product. I think a conservative estimate of that (assuming no scope creep etc) would be 24 months. Probably more likely 3-4 years.

The project I left had been worked on for 3 years and was servicable, but was not yet a 100% replacement for the original app. Like I said... even though it would have meant me not having a job, I don't think it should have been re-written.