Cost of Rewriting a PHP application to Rails or Django

Question

I am wondering your thoughts on doing a complete software rewrite. We realized after not long after we completed our software app that the framework was not going to scale well over time. For the record the framework was decided well before I got to the project. We are soon facing the reality that we will have to rewrite the entire app in a new framework. We are currently using a php. I have read in numerous places that complete software re-writes often fail or are extremely painful and time consuming. Does anyone have experience in this? Do you think that it would be wise to look at rails or django even though non of the developers know either very well? Thanks, I look forward to any advice you might have.

Answer 1

1. figure out what has to scale first, then choose a framework/platform that supports scaling in this manner. Note that you do not necessarily have to change languages/platforms, it may be that some simple redesigns can support the necessary scaling instead

2. then make sure you have unit tests to verify the existing functionality, plus additional tests to verify the scaling

3. then rewrite away, and good luck

it is easier to write an app well the second time (assuming the same team) because the first time you had to make a bunch of assumptions (how it would be used, what the users really wanted, what widgets would work well for situation X, and so on). Now that you have something that works, most of those assumptions have been proved or disproved.

Answer 2

Re-writing a doomed-to-fail application with a new technology/language that no one is familiar makes as much sense as saying "Well, the plumber did a poor job hooking up my toilet, I'll have the electrician do it." You are simply replacing one problem for another. (And probably getting your arse burned in the mean time.)

Re-write it if there is a compelling reason to, but use a technology/language those doing the re-write are familiar with in order to contribute positively to the re-write and increase the likelihood that the new effort will be successful.

If you determine that you do need to change the technology/language to support the requirements, then there isn't a whole lot you can do to eliminate a learning curve aside from hunkering down with some materials to learn it.

Answer 3

Joel Spolsky wrote a great article on how Netscape suffered as a result of a complete re-write. Not sure if this is the article you have read, but it's worth reading anyway.

Answer 4

" I have read in numerous places that complete software re-writes often fail or are extremely painful and time consuming."

Only when managed badly. Software rewrites also succeed. There are simple guidelines for success. Read Chad Fowler's.

The most important aspects of a rewrite are (1) preserving data and (2) doing the development incrementally. No one will invest in a massive rewrite project that takes months before it shows any results. Instead, you have to plan on running legacy and new software side-by-side until you've replaced the legacy.

Answer 5

Software rewrites typically fail for the same reasons that many new projects do: the inability to produce realistic estimates. If you can accurately predict the cost of the rewrite, and your are willing to pay that cost then the rewrite will be a success.

However, software engineers have a very strong tendency to be optimists, and they fail to account for all the intricacies that have built up in a project over time. In many ways a software rewrite is the ultimately well specified project (except for the tendency to 'improve' things or add features at the same time which can snow ball the problem).

I have been involved in complete rewrites that faltered due to feature creep and lack of good estimates, and also partial rewrites that have succeeded with varying degrees of success. In all cases the critical factor is being able to come up with the cost, without an accurate cost, you are only hoping to make the right decision.

Answer 6

A software re-write will totally fail if:

1. Specifications are not well laid out, even for the previous application. If the specs are unclear, many specifications that are specific to the behavior of the previous framework will end up being demanded on the new one even if it is inapplicable. Also, it would be very difficult to verify if your port is complete without a sensible set of specifications.
2. The stakeholders aren't interested. Sometimes a re-write is initiated not by the stakeholders, e.g., the clients, but by the development team, simply because they want to use something "new and shiny". Without an enthusiastic client (which would understand things like, delays in product delivery specifically because of the rewrite) you are utterly doomed.
3. The stakeholders expect totally the same application from the one they used to have. This is oftentimes utterly impossible. Framework changes often mean that behavior change is inevitable, but the clients wish the program doesn't change too much so that they don't have to retrain their people. You must make it clear to the clients that there will be changes, otherwise when you deliver your product your client will request changes back to the behavior of the existing products that would most likely end up as a project death march.

Believe me, project rewrites are a totally different ballgame from refactoring. Tread this path carefully

Answer 7

Fred Brooks warned about "second system" effect--the tendency of developers to gold plate & right all the perceived wrongs of the first system, even when the additional work was contributing neglibly (or even negatively) to the functionality & bottom line.

Of course, he also said "plan to throw one away--you will, anyways." I think he recommended building an explicit prototype, then building the "real system" leveraging the knowledge gained, vs. trying to rewrite a finished product.

You might try to discern how intertwined your domain logic is with your framework code--it's possible that you'd be able to isolate the domain logic into a library & put a new frontend on it with the new scalable framework.

Answer 8

It's case by case. But I would take "all rewrites are doomed" argument with a grain of salt. As I reflect on my own programming life, there has almost always been some rewrite/refactoring/porting of one software to another throughout. As times change, the paradigm and platform shifts, but the needs often stay the same. In a way, history of computer and programming has been a history of rewrite.

Running with a bad platform, non-database database backend, spaghetti code written years ago that's filled with duplication etc.., ultimately will drop the most important part of software, which is IMHO the ability to adopt to changes quickly. If you didn't want it to adopt to changes quickly you don't call it "soft"ware, you just make a hardware.

One example of complete rewrite was an opensource 3D sculpting program I and others wrote using Java 3D. After almost completing the whole thing, we realized that using Java 3D was a bad decision. I don't really remember what the actual reason was, but I think it was scalability, performance and availability on Linux or something like that. After some thinking we ported it to C++/OpenGL/wxWindow without changing any spec. I don't think it was big deal, partially because all the hard thinking was done already and there weren't too much dependence on the platform itself.

Rewrites can be successful, but the developers must resist the urge to add features until the porting is done. Not having a spec, will make estimation unreliable, and therefore the project will delay, and the project runs the risk of being abandoned by the market or the stakeholder. But that's nothing new. That said, rewriting definitely is a great opportunity to put in some top-down design decisions and "best practices" like unit testable, DRY, MVC, write-to-interface, coding-convention, collective-ownership code.

Answer 9

Since this is politically correct post with no actual framework mentioned. I will talk theoretically.

First what I did when I had similar problem is that I did rewrite in stages. I had horrible php app at client site and I suggested rewrite of parts in either PHP Code Igniter (very good performance) or Rails. Reason for doing this in stages was because of desire to be agile and also knowledge that waiting too much for new app might kill the project. We spend some time figuring out what would be good way to approach it and once we isolated parts we want to rewrite, it was fairly easy to work with that. So maybe it is easier if you split the problem into several parts (stages), since db is the same, you just move parts of it to new framework/rewrite. Once you have parts working, just point urls to that place. One thing that helps is to refactor a little modules/pages you intend to rewrite before you start rewriting them. I found this helps me understand logic better.