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 m

Answer 1

Having been on a project where we did the app and the database all at once I would recommend trying to get the database correct first and then doing the app after that.

Trying to do both simultaneously could prove very painful. However without being next to you looking at the code it is always tough to say for sure.

I just always feel that if you have the database and you can rely on it you should be able to rewrite using integration tests and then unit tests so much more reliably.

Once you have the database solid I would think a best case scenario would be to try and modularise the code into separate and reusable assemblies (which you should be able to use in .NET) and then gradually mograte those to .NET from VB. That might not be possible if the code is horrendous smelling spaghetti!

Answer 2

Start converting the different modules one at a time, phasing them out of the VB6 application.

Prioritise according to what is mission critical/strategic, so you can also add value as you go along.

Since the database will be the integration point, make sure you fix the relevant parts (relavant to whatever you are working at the time), so you are building on a solid foundation.

In the short term, you will have more work (both VB6 code and .NET to maintain), but with a cleaner architecture, you will be able to start moving away from the legacy application faster and faster.

This way you will have both systems running at the same time for a while, so you have a fall back, and you can add proper structure (architecture, database integrity etc).

Answer 3

It sounds like a major job to rewrite the application from scratch, especially since there are no unit tests and you are not the original author. I think that an incremental approach is probably the best, starting with adding unit tests and re-factoring the code so that can be unit tests in order to capture the functionality of the application. Then incrementally improve the app as time goes by instead of putting on hold. A rewrite is often easy to underestimate if you are not the original author as there could business logic in there that is not obvious.

Answer 4

That was a great write up. However IMHO its missing an important piece. What is the value of the rewrite in terms of the customer and what are the costs and risks. I'm guessing here but it might be the following

Customers may get the following

1. faster defect/enhancement resolution.
2. Lower likelihood of new defects during deployment
3. Larger developer pool to hire from
4. May be able to implement features that were impossible in the past

Costs/Risks

1. Near total loss of current investment
2. May introduce defects that were solved in the past.

You should consider what you can do to mitigate the risks and also see if the value your adding outweighs the risks and costs.

Answer 5

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.

Answer 6

I think it might take you quite a while (too long) to rewrite a 100KLOC application (including reverse-engineering the specifications, and testing), without help.