This is a web application for payment processing. I've been here maintaining it for nearly two years now, so I have a good idea of the problems with the system. About a half a year after starting here I started a rewrite in php/mysql that ended up not getting used (not because of good reasons like "it hasn't been tested" or "how do we know if it will be stable?" but "php/mysql are not microsoft and are therefore bad" and "we have to buy a license for mysql / we'll have to share our source code if we use it / no shops use anything but microsoft products" - those were thoroughly entertaining conversations. This ended up being a fully functional throwaway prototype. I wasn't happy with the end result (mostly with how the HTML was coupled with code, it would have been hell for a web designer to work with), but it worked and at least I gained complete insight on the input/processing/output of the entire system.

The current system we are using works, but is fragile and difficult to add features to without breaking something else or requiring lots of manual fixes down the line. But is it bad enough to need a rewrite in order to move forward and meet the requirements and features new potential clients? I think so.

Here's a list of code smell:

Originally designed in Visual Basic in 2003 or earlier, no major design changes since

No classes or any kind of object-oriented design

3700 line Module1.vb file

Manual deployment of executables and aspx files

Complete mess of HTML designed in 2003, under-utilized stylesheets

New clients were created by copying and renaming pages and functions

Copied function names, e.g. function1, function2, function3

Highly coupled with SQL Server

Redundant database connection->command->reader blocks

Highly coupled with our current payment processor

Lots of functions with 6 parameters (many byref because there are no classes)

No unit testing, have to debug from the start of the application to the finish every time

No consideration for security

Coding style is completely inconsistant, save for what VB does

Settings (including passwords) are hardcoded in compiled files (besides those I've moved to web.config)

Comments are either dead code (found everywhere, sometimes up to 50 lines), stating the obvious, or non-existant

Extremely fragile - during revisions, changing code in one place affects stability elsewhere.

I fixed a byref parameter of one function to not always be empty (so it would actually put a value into the variable it was supposed to be getting, but who could tell if it was used or not?) only to have a block of code with an obvious flaw (that had been there for over 5 years) suddenly start working.

No test objects - all test data is retrieved from live databases or copies of live databases

This question came from our site for professional and enthusiast programmers. Votes, comments, and answers are locked due to the question being closed here, but it may be eligible for editing and reopening on the site where it originated.

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.
If this question can be reworded to fit the rules in the help center, please edit the question.

I'm not sure what your question is ? Do you need a rewrite ? It's really not over this that I would look at it. How much does it cost to add a feature and is it feasible vs how much does it cost to rewrite the entire thing before adding the feature.
–
YahelJan 27 '11 at 16:20

That's what I thought, but wasn't sure. Can it be moved?
–
ChrisJan 27 '11 at 16:22

6

Mine it for dailywtf. Then start looking for a new job.
–
Tom AndersonJan 27 '11 at 16:26

2

What did your boss say when you presented the above list?
–
user1249Jan 27 '11 at 17:43

1

Two years? Man, you are a demigod or something. This just sounds plain painful.
–
sovaJan 27 '11 at 20:41

Then, find whatever duplication you can and start abstracting into classes, etc.

Then, look at the beauty that is left.

The steps don't need to be in this order, obviously, but after each step, test, release, refine, refactor some more. Create tests as you go to ensure you don't re-break things! It's a long road. And in the end, none of the original code will remain. But, you get the benefit of being able to test incremental changes/fixes in a live environment with live testing. Rather than trying to create a huge rewrite, and dreading the "go-live" day because you don't know what will be broken.

As you are fixing bugs, and maintaining existing functionality, leave each page, function, etc a little better than you found it.

Rewrites NEVER go smoothly. You're trying to maintain v1, will building v2... and you end up in a race you can't win. You end up missing a critical feature. You end up with code that has a new set of unknown bugs because it doesn't have years of use and real live testing.

I have to add, this does work. I just did it on a medium sized app. There were many days I was removing thousands and thousands of lines of dead code. Reducing files from 3500 to 300 lines (no joke) with no changes in functionality. A tool like Resharper helps immensely with this. Replacing dozens of lines convoluted and buggy string manipulation with a single regex. Creating classes and interfaces to start reducing the number of parameters that functions took. Now, the engine of this app is a thing of beauty. And it didn't take a rewrite. The hard part was not breaking secondary apps
–
CaffGeekJan 27 '11 at 22:53

1

Strongly disagree. Something that bad cannot be easily refactored without reworking half of it anyway. A rewrite is the correct answer in this case, because the thing is completely outdated and uses no good practices at all. If some practices were used, refactoring could save it, but this is akin to giving "treatment" to a leg that has suffered gangrene; the only solution is to amputate.
–
Wayne MMay 27 '11 at 18:08

@Wayne M. You're free to disagree, but the app, mostly works. Why throw that all away? Refactor bit by bit, maintaining functionality, and the ability to keep the app running. By starting fresh, you end up with a race between getting the new one done, and changes in the old system... and then having to make those changes in the new system, etc, etc
–
CaffGeekMay 27 '11 at 19:02

Are you asking the right question to the right people? It sounds to me like you already know what the answer is (or at least what you want it to be).

You have identified numerous (technical) problems with the existing source code, have even done a rewrite (in your own time? or did the company provide time?), but still management apparently doesn't listen.
To summarize your argument:

It's difficult to know where to make a change

It's difficult to know how to make a change

It's difficult to know what other functionality is affected (broken) by a change

It's difficult to test changes

An unnecessary amount of attention is required to keep the system running

What arguments has management given? Are many changes required? How much do they think a rewrite costs? How much risk do they think is associated with it? Can you convince them otherwise? How much time will they save in maintenance when the rewrite is done? How will the customer be happier after a rewrite (less bugs, better performance, ...)? What alternatives to a rewrite exist (keeping the old stuff, refactoring bit by bit, ...)?

And don't forget: How will your work satisfaction change? How strongly do you feel about this? If you are willing to change jobs to avoid working with the existing system, I think you should let them know. Of course you should be careful how you say this, you don't want it to become a pissing contest which ends up getting you fired, but it helps to let them know you feel strongly about this. Maybe something like 'maintaining a system like this is not what I see myself doing down the line'.

Of course, it is possible that you will just have to agree to disagree. But if their arguments are just wrong and nonsensical (nobody uses PHP? only MS is cool?), maybe it is time to move on.

[update]
Just a warning to add: a rewrite won't keep you from having to support crappy code, it will just change old crappy code to new crappy code (hopefully less crappy, but you can't be sure yet). Looking back, and having learned in the process, your new code will look crappy too. You will only know how to do the rewrite correctly when you're finished with it.
So proceed with caution.

There's one thing I would like to add to what others have said: once you've broken functions/methods down into smaller (and sanely named) ones, write - however difficult that might be - quick unit tests here and there. Try to get into the habit and stick with it.

Every chunk of code for which you have a test can be seen as "some more safe ground" upon which you can walk with more confidence than before towards the next change.

At the company where I work, we're about to rewrite a big, very complex application which is now written in VB6 to bring it to the web.

Without going into too much detail, I can grant you I would rather be in your shoes: only two developers on the team, bugs to fix and implementations to be done in the current version and the management assigning idiotic tasks every few days.

Any of us can tell you that the code merits a rewrite. However, after that you have at least two more issues:

How do I convince management?

What's the best way to manage working on two codebases on the same time to ensure that maintenance fixes are also included in the rewrite?

The second question above implies that you will get management approval. Given that they've already declined to use a rewrite you've prototyped, approval for the rewrite seems questionable at best. An alternative strategy is to clean up code as you go along where possible. Over time, the code base will improve and your fixes will be faster.

[adding another answer, since it's a different aspect than my previous answer]

Elsewhere you mention the customers are unhappy, and one wouldn't be a customer if he didn't have a contract. Others have mentioned rewrites never go smoothly, and will have bugs and/or missing features when delivered.

If you are going to do a rewrite, try to get the customer(s) involved as much as possible. Try to make them feel like they are part of the team making the new software. The more they feel like they are involved in it, the less they will criticize the final result. They will better understand that it won't be flawless from day one, and know where to take their bug reports.

You can use that to sell it to management as well; it will distract the customers, they see something is being done about their problems.

Assemble a list of customer complaints. Track their time to resolution and the issues you had with the code base in resolving them. Use that as your driver for being assigned the time to handle the technical debt.