A clash of styles

I have recently been asked to merge two seperate vb 6 applications into one. One of them is a well written, well designed piece of software that uses classes, collections, is well documented, coded etc, in short a piece of work that was clearly written by a pro. The other is a ball of mud that has grown out of excel macros and ended up as a vb6 application. Both use the same oracle database and there are clear and obvious advantages in merging the two. The problem is I just want to rip the bad one to pieces and start again, adopting the development style of the other. the reallity is I could just cut the bad one as a dll and include it into the merged application (slight exageration but you get my point) - Oh the pain, it's doing my head in.

We all know re-writes are bad, but in this case what do you think, worth the re-write or not? I am only replacing existing functionality, i.e no added features.

You jumped straight to Ch 10, didn't you?
Thursday, December 18, 2003

Go the DLL route first. Get the merged functionality working and then as you find "issues" in the poor quality code base refactor or rewrite as required.

You'll probably get "something" working faster this way and you can then focus on the real problems with the ball of mud rather than focusing on what you think the problems are likely to be.

The users just wont appreciate you saying "wait 6 months and I'll deliver it and it'll be lovely inside" if the alternative is "I can let you have it by the end of the week but it will be a pig to maintain in the short term".

It's actually quite rewarding to chip away at a mess like that and slowly make it more robust and more maintainable whilst continually providing working code to the users.

Len Holgate (www.lenholgate.com)
Thursday, December 18, 2003

Take the application as your starting point and slowly work the features of the ball of mud into it. As you do so, pick clean the code and sort out the problems.

Mr Jack
Thursday, December 18, 2003

Agreed, being able to take these two applications and merge them so that they work in a very short amount of time is "A GOOD THING".  But make a note at the time of release that you are going to spend some time refactoring and cleaning up the code so it can be maintained in the future.  If you release a working version fast enough you shouldn't receive any flack about this request.

Lou
Thursday, December 18, 2003

As Len says, encase the ball of mud in a concrete enclosure (e.g. separate DLL) but with new clean interfaces that for now tie into the mud. Then one-by-one you can rewrite the interface methods as time permits to point to new code, until everything is new and you can throw out the mud.

Jack Tripp
Thursday, December 18, 2003

I agree with Len and Jack.  First, make it work.  Then make it right.

I know the pain you feel about taking the ball of mud and "integrating" it with a clean application.  Perhaps you could ask for more time than you'll need to just make it work and use the "extra" time to make it right.

-Thomas

Thomas
Thursday, December 18, 2003

Great Comments, and good advice, I think I'll do just that.

Cheers

Ch 10
Thursday, December 18, 2003

  Recent Topics

  Fog Creek Home