Refactoring PL/SQL to Java

[Joe Bothari]

Greetings,
My team has just finished a two year project to move about half our web site functionality from PL/SQL to Struts. It was supposed to be a one year project, but you can imagine what happened.
As we catch our breath and gear up for the other half of the web site, can you suggest some stratigies that might let our management keep their jobs? I'm reading Fowler's Refactoring book, and I'm trying to find a good testing suite and get it integrated before we start. Also, any people-skills type ideas for selling good software practices would be appreciated.
Thanks,
Joe

[Lasse Koskela]

Take smaller steps? That should give your management more points of contact with reality and opportunities to improve on the team's estimation skills.

[Joe Bothari]

That's a really good point. I'm learning more about the Agile software processes now, and that's one of the main principles.

The big problem with that is that we just finished up a software process improvement project. It took EIGHTEEN months to come up with a waterfall process. One of the quotes that came out of the meeting was "We don't iterate."

I believe one of the early steps for this migration will be to split the site into a presentation layer and business logic layer. This is really encouraging, because it might allow us to replace the pages piecemeal.

Any other tips on refactoring across languages AND technologies?
Thanks,
Joe

[Alexandru Popescu]

Even if this is not related directly to refactoring I would suggest to establish a series of functional milestones. This way you will get the feeling that you are going the right way (or it will be a good point to turn back and change the way you see the solution).

./pope

[Lasse Koskela]

Originally posted by Joe Bothari:
The big problem with that is that we just finished up a software process improvement project. It took EIGHTEEN months to come up with a waterfall process. One of the quotes that came out of the meeting was "We don't iterate."

I take it that you're working for a Fortune 500 company?

Seriously, try to not sell those smaller steps as iterations but instead propose "delivering faster" or "delivering more often" or something like that. Or "improved control over progress". Another option might be to let management keep their one-year waterfall lifecycle but do your part of the waterfall in small pieces. At least you would know early if something in the schedule starts to smell.