Traditional HTML/CSS/JS + PHP vs. Flex + Java Servlets -- a little more than that

Question

So the situation is a bit complicated. There was one graduate student who was developing this web application by himself using Flex and JSP. He moved on with his career and took a job somewhere else. He still has access to the application and frequently maintains it.

Along with couple other students and I took over the project the grad student built to fix some issues and improve the application to the point where we can deploy this website to the public for academic uses. The purpose of the application is not important here, but we are having trouble with this application.

None of the source code has documentation. It takes us hours and hours to just figure out how things are connected and coherently work (or does not work). Although we know and familiar with JSP, we are not so familiar with Flex. I thought it would be interesting to learn new client-side technology before I took this project.

After few weeks of looking at code and investigating problems, I found out that even Flex codes are not organized properly. There are many hardcoded values. Source code is totally NOT MODULAR and NOT SCALABLE. The examples or articles I read about developing in Flex are different from how this Flex app is built.

Because of all these overhead that we have to deal with before we even get started to look at the real problem, we suggested to change the whole application into using PHP (possibly using CakePHP...let's not discuss which PHP framework is better) with traditional client-side languages -- html, css, js (jQuery framework).

The grad student thinks that this is a bad idea, because it will take us time to get the new app to where the current app is.

I understand that we will need to spend some time in order to come back to where we are right now. However, we would not need to ask this grad student with things that we don't understand and wait for replies. We also don't have to deal with ugly code and no documentation. We can learn how PHP framework works and build an actual application out of it. Users also don't need "flash player" to access the web app to its fullest.

The grad student came with this statement that he does not see how PHP would be better than JSP.

However, I don't see how JSP is better than PHP, because there are so many good frameworks and tools for PHP development nowadays. I see a lot of successful stories with PHP (not that I don't see ones with JSP, but PHP can do whatever JSP can do).

So, I'm asking this to StackOverflow Community, because I know the community has people with way more experience than I do in project management, development, and education. What do you think I should do? Should I stick through the project and just continue developing in Flex/JSP? or Should I convince that building everything from the scratch (well, we will still use the old implementation as reference)?

Please help me out here. Also, tell me why I need to stick through or change.

Sorry for the long post.

Edit
Some other problems that I did not mention are...
1. For some reason, the grad student worked on the server directly instead of creating a local workspace or making a test/development site. I don't really like this idea, and when we were trying to bring things locally, it was giving us a lot of problems due to the fact that many things are "hardcoded". We sometimes don't even know where the error is coming from or why things are not working the way it does on the website because obviously, we don't know every piece of code.
2. No document means absolutely no document. No comments in the code. No functional specs (although as I play around with the site, I find the major functional specs). No database schema. Nothing. Nada. This is the most frustrating part, because I always feel like I'm wasting time by trying to figure out what is already working -- I need to see how things work or are supposed to work to fix bugs..right?

I would also like to get some feedbacks on technical advantages and disadvantages of having Flex/JSP, besides the cool, fancy UI Flex has to offer.

Answer 1

I don't think that its a question of is PHP or JSP better, a good programmer can write good code in either. Documentation really shouldn't be a big deal either, if the code is well written it should explain itself. I think the questions you should ask is do you have time to rewrite it? and if its re-written will be worth it?

It sounds to me like your problem is that you have students writing the code. They are students and are all going to write crappy code until they have written a few apps. Have a developer with some experience re-write, maybe with help from students.

Answer 2

This is essentially a question of rewriting versus refactoring. While rewriting is sometimes necessary, its almost always preferable to refactor the code. For one thing, rewriting will almost always take longer (if not always) than refactoring, and for another, rewriting may fix lots of bugs that you see in the existing version but it WILL introduce new ones. Refactoring should allow you to leverage the existing good code while only changing the code that has issues.

I would strongly recommend that you consider writing up a spec document with the grad student's and professor's input so that you can define what the application ought to be doing. Then, define what it does currently. This will give you an idea of what features are missing.

Once you define all of this you'll also need to define what features don't work right. Basically, this will allow you to identify bugs.

First, fix the bugs. Don't write another new feature until you've got all of the existing bugs ironed out. Then refactor the code. Test to make certain that your refactoring didn't introduce new bugs.

Then start writing new features. Again, refactor mercilessly and make certain that you test your refactored code frequently.

I would suggest that you read this post from Jeff on Paying Down Technical Debt. One comment that either he made or that I read on one of the links in his article is that you want to make certain that you mark any cruft clearly so that when you come back again, you know exactly where to begin refactoring.

This will ultimately give you a running application, albeit not a perfect spotless one much faster.

Some additional considerations that you mentioned:

Flash Player

Seriously, almost everyone has it installed. The number of people that haven't visited youtube at least once or some other site that utilizes it is almost negligible. The question here should be whether Flex was the right tool in the first place? I've seen examples where flash was used 'cause its what the original development team knew. Try to avoid the situation where "When you're a hammer, every problem looks like a nail."

Learning PHP better or learning a PHP framework

This is a question of objectives. Is this project purely something for you and the rest of the team to learn with or is someone (like the professor) actually expecting to see some results from this project? You'll have to weigh the benefits of leveraging your existing knowledge with the current technologies being employed against any perceived gain in using the new technology. Keep in mind that you'll probably be in for a number of surprises as you go along where you'll find out that your recommended "new" technology for the project will fail to do something and then you'll likely lose time trying to figure out how to get around the problem.

Answer 3

Without a back-end or tag libraries PHP = JSP. There is no real difference between the two. However, JSP is usually used in concert with a middleware framework (in j2ee) and tag libraries which make them somewhat easier to read. If it's not being used with one of those, then yes PHP would be a drop-in replacement.

As to the more philosophical problem of a rewrite. Rewriting any web app which is complex enough to give you so much trouble understanding the original code will take you a long time. Think 4-5 months, as you're basically building from scratch. You're probably thinking 6 to 8 weeks, you're wrong. ;-)

Usually, your gut instinct is to throw it away and start a new one. Fight that instinct. We're all lousy at writing readable code and even worse at reading it. If you've only been working on it for two weeks or so, it's probably not as bad as you think. So ask yourself the following:

• do you have 4 months of development time to simply reach feature parity?
• is the code really that bad? There's no encapsulation at all? Couldn't you just replace some key parts that you need to work on with better written code? (preferrably in the same languages as the rest)
• how certain are you that your version will actually turn out better than this other person's code? After all, you didn't write the original so you cannot apply any of the lessons learned in building that to building the followup.

Before you throw something away (something that might have involved a lot of work), make sure there's really no way it'll ever work. Otherwise, you're just setting yourself up for more stress.

Answer 4

I have been part of too many "rewrite from scratch" scenarios, where a new team comes in to rewrite what and old team has done, because the code is so crappy, and they spend too much time focusing on what the old code did "wrong" so they could fix it, they never really investigated what the code did right, so the new application failed in other horrible ways.

My suggestion would be to rewrite the code, but use the same technology... either use flex or JSP, or JSP by itself. This allows you to refactor fragments of the existing code and leverage the problems already solved.

This allows you to rewrite the code piece by piece and have milestones and eventually phase out the bad code.

Answer 5

It sounds to me like you have an inexperienced grad student write this application (he might be a little arrogant as well).

I would suggest try to refactor, not rewrite, the application. Try to reuse the current technology (JSP and Flex). You can work with the grad student, or get someone else that has experience in Flex/JSP, and work alongside to make sure the code is refactored appropriately.

Re-writing will only introduce more bugs, and omit already working functionality.

I think what happened is the grad student was allowed to create without any supervision (think leaning tower of Pisa). It's ok to let creativity flow, but make sure it has a path to follow. Otherwise, you'll always find it flooding you.