6

Possible Duplicate:
I’ve inherited 200K lines of spaghetti code — what now?

For my next project, I've been tasked with "overhauling" a large legacy web application with many parts. It is a JSP application written in 2004 and it is used heavily by my company.

This application was designed badly in that there is no separation of concerns; no service layer, no DAO layer, no MVC structure. Just a bunch of JSP files loaded with scriptlets containing logic and database queries mixed in with HTML. It's a mess.

My boss has defined "overhaul" as basically rewriting the entire thing using the technologies we use for our more recent applications, which are:

  • Maven
  • Spring
  • JPA (w/Hibernate)
  • JSF

AND add a bunch of new features.

My question is: How do I go about this? What should be my strategy for completely redoing a large application that is currently in use AND add a bunch of features?

Should I rewrite the existing application first and get it working with the updated technologies and THEN worry about adding new features afterward? Or should I go about it like I'm creating a whole new application and implement the new features WITH the old features?

Has anyone done this successfully? If so, what strategies were instrumental to your success?

Edit: More info from comments:

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.

Community
  • 1
CFL_Jeff
  • 3,517
  • 23
  • 33
  • 8
    ob Joel on Software: [Things You Should Never Do, Part I](http://www.joelonsoftware.com/articles/fog0000000069.html) –  Feb 05 '13 at 20:24
  • 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? –  Feb 05 '13 at 20:27
  • @MichaelT Haha Somehow I knew someone was going to link to that article. 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. – CFL_Jeff Feb 05 '13 at 20:30
  • 1
    "Working Effectively with Legacy Code: Michael Feathers" (another mandatory suggestion on any Question with the word Legacy in it's title..... ) – mattnz Feb 05 '13 at 21:22
  • @mattnz continuing on that, his blog post of [StranglerApplication](http://martinfowler.com/bliki/StranglerApplication.html) is a useful read. –  Feb 05 '13 at 22:06
  • `the guy who originally wrote it is now in upper management.` Well at least he is still in the company so I would say that you have one huge advantage over most people who are tasked with rewriting an awful legacy application :) – maple_shaft Feb 06 '13 at 02:46

3 Answers3

9

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.

Tyanna
  • 9,528
  • 1
  • 34
  • 54
  • 1
    +1 For an excellent answer, this **Horizontal Layered Rewrite** approach is good if development isn't necessarily driven by features, however I feel that because it is so widely used that it may be best to slowly rewrite the application vertically by features, that way users can slowly become acclimated to using a new application for certain features as they are slowly rewritten. This of course assumes that the underlying foundations like the schema don't need refactored as well (which is probably the case) so perhaps a combination approach is needed. – maple_shaft Feb 05 '13 at 20:59
  • Speaking as someone who has written a legacy app from scratch I can tell you, sometimes it makes sense. Yes, it is hard and VERY time consuming but not only can it be done but you CAN come out with a better product. – Lance Feb 05 '13 at 21:29
  • 1
    @Lance ~ I don't think there is a way of replacing a legacy app that isn't hard or time consuming. It takes a serious effort no matter what path you take. It needs to be something that is well planned and thought out and not done just "b/c the old code is bad". – Tyanna Feb 05 '13 at 21:47
  • 1
    I absolutely AGREE! I was just saying that there are times and reasons to do it. When we did it, it was multiple MONTHS of planning and diagramming before one line of code was written. So of the code was poorly written but that was NOT the reason for the rewrite. I agree again I would do a re-write just because I didn't like the code – Lance Feb 05 '13 at 23:34
  • @Lance And as the technology gets old, finding talent willing to work on it is harder and more expensive, the revolving door problem happens and then nobody is left that truly understands the legacy application any more. Existing documentation is helpful but old documents are static and sometimes not reliable. Heavy amounts of diagramming and planning are necessary like you said, just so the current team truly understands the scope and brevity of what all needs to be done. – maple_shaft Feb 06 '13 at 02:41
2

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.

  • 1
    I like this module by module approach. It gets the users using a new application for a limited set of features early, so the shock of a brand new system all at once doesn't bring risk to the project. – maple_shaft Feb 05 '13 at 21:00
1

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.
scriptin
  • 4,432
  • 21
  • 32