I wouldn’t suggest doing a rewrite a whole application. Especially one that is currently being used by the customer. You will never cut over to the new system until it can do everything that the old system does. While you are writing the new system, the customer and management are going to get impatient and want those new features. You, or someone else will have to add them to the old app, which takes away time from the new app, and will just pile on more work that you have to do before it’s completed. The chances of you actually completing the project go down as time goes on, until you feel like you’re on a never ending project and moral starts to go down.

Generally, a bad idea. As MichaelT link above states.

So what to do instead?

Take a good hard survey of the current code base. Find the good, the bad, the ugly, and the down right frightening. See what can be cleaned up quickly, what can be reused and refactored, what is no longer used or needed, and what needs a rewrite.

Design and implement your new DAL. Look at the pages and the code and detangle it so you have a separate Business layer calling that DAL. Focus on like pages at a time. Release as they are cleaned up and ready. Make it more iterative. You might have to hit these pages more than once, but make sure to leave them better each time.

When a new feature rolls in, b/c you are going to get more than what is currently in your pipe line, incorporate them into the clean up effort. When you release a new feature, release new cleaned up code at the same time.

Will this take some time? Yes. Yes it will. I’ve been with my current company for 3 years and the web client application I’ve been cleaning up isn’t done. But, we have had numerous major releases, and sold it to many different clients. It now works on more platforms, and it is getting easier and easier to make new pages and features for. If we had of decided to start from scratch and release when done, well, it’s still be a work in progress, and we would have no major releases or clients to show for it.

How much business logic is hiding in this application? Do you have the
full specs at the start? All the requirements changes over the past
decade? All the bugs that have been fixed? All the bugs that are still
open? Comprehensive regression testing suite?

To which was answered…

How bad does the design have to be to justify a rewrite? This design
is pretty bad. There is tons of business logic hiding in the
application. No specs, no logs of requirements changes, no list of bug
fixes, no list of open bugs, no test suite, no documentation. And the
guy who originally wrote it is now in upper management.

You’ve got a application that is a decade old, with no documentation of what it really should do, what was done to fix it, or what it isn’t doing right.

There are two approaches.

The first is to slowly rewrite it from within. Go in, find a module, figure out exactly what it does and what it should do, and replace it. This is a gradual process. It is likely the best approach. It isn’t something that management tends to like (I have found that management tends to like big projects that look big and have big releases). Replacing something from the inside that doesn’t look like it is doing anything doesn’t get accolades.

The other approach is to go and throw away the original and start over. The question is “how long will this take?” is one of the first questions that is asked. For this, one can get a reasonable estimate.

Given no documentations, a complete rewrite, such find out how many lines of code the application has and toss it into the COCOMO II model. This works on the assumption that it will take about as many lines of code to write the new code as is there existing now. See how big it is.

The question of is this a good idea for the business to undertake isn’t one that as programmers we should make. We have opinions on it, and may think this is a terrible waste of time or that this is something that would be great fun to do (I strongly suggest reading Death March to get some perspective on this) – but we are not the ones that make the calls for the business.

Identify the time frame that this will take, and let the business decide if there is a justifiable return on investment.

Remember, there is a third option – leave it like it is.

Has anyone done this successfully?

Here is the success story of our company. For a pretty long time we had a messy website:

• PHP/MySQL, mostly Drupal 6.
• Many custom Drupal modules of medium quality.
• Some really old legacy code parts written in plain PHP+SQL+HTML+JS+CSS (there were files actually containing all of those at once). Those were actually very important parts which came from older version of the application.
• Two internal MySQL databases (one for Drupal and one for older stuff), two external SQL Server databases which our app was integrated with (all with just direct queries).
• No spec, no tests, even no repository (we made it later).
• Cannot tell the size of codebase now, but there were about 12 custom forms and about 10 custom Drupal modules. Many features were implemented just with modules from official Drupal repository, so it shouldn’t be counted as a part of code we wrote/maintained, but rewrite was done with Kohana framework, so pretty mush everything was done from scratch.

The good news were:

• Before we redone it, I had over 1 year of maintenance/extension experience of this app, two of my colleagues had about twice less time of such experience. One last guy had no experience.
• Through the maintance period we gradually improved some parts and found most of pitfalls and undocumented features.
• Before rewrite we managed to make a specification of some sort.
• In the last few months we added some new parts which we were going to keep in the new version. Some of this code actually was transplanted.

How it happened:

• It was done mostly by two guys, one of them was the guy with no maintenance experience. I helped with spec and just a little bit with code. One guy maintianed the old version through the process.
• It took slightly more than half a year, but partially because managers stuck with getting a new interface concept and graphical design. Just coding could be done in 4-5 months, I think.
• Pretty much all old features are now implemented, some of them even slightly improved.
• Some rudimentary unit testing was done (but not TDD/BDD), I’ve not looked into it yet.

After all, new version is online now and we have no major problems.

It was not a 100% rewrite because:

• We took some (but little) code to the new version
• Old version was actually undergoing the process of gradual improvement, so it was not a huge “paradigm shift” for us as developers

Without that much of maintenance it probably could not be done. I tend to agree with other answers in that full rewrite is generally a bad idea, but as our story shows, it is possible given those conditions:

• app is not very big
• team is not very big (4 in our case)
• most of team members have extensive knowledge and experience dealing with legacy code

For your specific situation I can suggest you:

1. Try to improve what you have. This will at least give you the deep knowledge of your app.
2. If improvement will work, consider just continuing on improvement even without switching to your current technology stack. A bird in the hand is worth two in the bush, you know.
3. If improvement will fail, rewrite will be easier and faster because of the clause 1 in the list.