Would you re-design completely under .Net?

Question

A very extensive application began as an Access-based system (for database storage). Forms were written in VB5 and/or VB6. As .Net became a fixture in the development community, certain modules have been rewritten. This seems very awkward and potentially costly just to maintain because of the cross-technologies and extra work to keep the two technologies happy with each other. Of course, the application uses a mix of ODBC OleDb and MySql.

Would you think spending the time and resources to completely re-develop the application under .Net would be more cost effective? In an effort to develop a more stable application, wouldn't it make sense to use .Net? Or continue chasing Access bugs, adding new features in .Net (which may or may not create new bugs between .Net and Access), and rewriting old Access modules into .Net modules under time constraints that prevent proper design and development?

Update The application uses OleDb and MySql - I corrected my previous statement.

Also, to lend further support to rewriting: I have since found out that when the "porting" to .Net began, the VBA/VB6 code that existed was basically translated to the .Net equivalent. From my understanding, nothing was done to improve performance, or take advantage of new libraries or technologies.

In my opinion, this creates a very fragile and unstable application. With every new update, this becomes more and more visible. As a help desk technician, I have noticed an increase in problems reported. The customers using the software have noticed an increase in problems and are commenting on it.

Answer 1

A lot of people discourage rewriting an application from scratch and sometimes I agree with the reasoning. But most of the times I find rewrting the app the least painful solution and anything written in Access needs to be ported to .NET - PERIOD. Don't get me wrong, Access has its place and can provide alot of functionality to an organization, but if it turns into a full-fledged app that people rely on then it has out grown Access.

It would probably not take much time to port the extisting VBA to .NET in a one for one conversion. But that may not be a great solution if the VBA is not very good to begin with. A redesign/rewrite will take longer to write but will in the long run be much easier to maintain.

I am almost always in the camp of rewriting it from scratch where Access is concerned and have not regretted it once.

Answer 2

I agree with the refactoring approach. It is quite likely that this will be a slow process that may take many months to complete, but by moving one feature / section at a time has major advantages including:

1. Product features are maintained.
2. ability to deliver a new release is maintained.
3. Time pressure is removed.

Good luck

Answer 3

It is generally a discouraged practice to "rewrite" an application from scratch (which is a normal urge most programmers felt at least a few times in their lifetime) because you will go from an app with known feature set (and known bugs too!) to an app with most likely lesser set of features and more importantly - unknown bugs. Users could get frustrated, etc.

You would probably be better off if you slowly refactored your app over a period of time, thereby evolving it's architecture over a longer period of time.

Answer 4

A big challenge that I experienced with a rewrite of that scale is having to maintain two codebases at the same time. If you fix a bug in the legacy system, you have to make sure the functionality works correctly in the new system, and vice versa. Upgrading one module at a time minimizes that maintenance headache.

A full regression test suite that runs on both the legacy and replacement systems would also be helpful.

Answer 5

I agree with Jas, don't rewrite apps just for rewrite sake. They may never need to be debugged or improved, so why waste time? However, if you feel there is a moving shift in the expertise of your new developer hires away from Access to .NET, you may have to migrate before it's too late. That seems unlikely, but a possible consideration.

Although it may not be profitable from a development standpoint, how is having different applications spread around affecting users? Does it require more user training? Are they making more mistakes. Does it increase the number of support calls because they can't find something?

Answer 6

"Would you think spending the time and resources to completely re-develop the application under .Net would be more cost effective?"

This is not a question that can be answered here.

From the top of the requirement pyramid: someone made a decision which he hopefully can justify with a business plan. In that business plan it should state how many hours+extra costs it takes to convert the application and in that same business plan the benefits are stated also in terms on money.

That is the way to do it. If there is no business plan for it. then the answer is to first work on a business plan traceable to some high level use cases to make the impact analysis to verify the start of the project.

If the original driver of the business goal leading to the change is not even based on money then this person is probably the one paying for it all so it must be done.

If there is no business plan but "it just is done" then try to make one and present it to upper management. Include high level uses cases, costs, hours for redesign, build, extra cost for operations, new training for admin and endusers, project management and potential risks.

IMHO this is no technical question.