ActsAsFlinn

Some of you might have seen the O’Reilly article by former Rails trumpeter Derek Sivers entitled 7 reasons I switched back to PHP. Or the Slashdot article, even more ominously named Thinking about Rails? Think Again. In typical fashion, Slashdot ran the link with a suggestive name which I’m sure will effect the credibility of Rails in the eyes of the uninitiated masses of PHP developers trolling the website.

I happened to read the article earlier in the morning before it made it to Slashdot and didn’t think too much of the arguments behind the article. I can honestly say from my own experiences that mismanagement of a project, not limitations of a framework or language are usually to blame for missed deadlines, and project failures. I can say that from experience after developing the same project in both PHP and Rails with about 1/3 of the tables (and probably logic).

Anyone with a lick of common sense can tell you that if you’ve got a legacy application with 90 tables, migrating that data and accompanying application to an MVC framework is going to be a big project. With a 2 person team, 1 of which is the owner of the company (who should be focusing on more important things), the project is going to take a long time, cost a lot of money and the likelihood of failure is high.

I think Derek’s logic and motivations for pursuing the project should be at question, not his choice of programming language or framework. Why do companies go into business? To make money of course. What possible reason does a company then have to rebuild it’s entire infrastructure from the ground up? To either make more money, or save money ie. make more money. The 7 reasons he switched back should have coincided with business considerations before he started the project not after the project failed. I think it’s shameful to place the blame of the project’s failure on the language and framework choice.

I’d love to hear what bitsweat honestly has to say about the project but we can be sure either an NDA or professional courtesy will keep that from coming out.

The comments at the end of the article do this opinionated scapegoat of an article justice.

Useless post without a concrete illustration.

Show us an example of:
1) What you tried to accomplish.
2) How you tried to implement it in rails.
3) The rails code that "didn't work." 
4) The "beautiful" PHP code you created instead.
Richard Hertz | September 22, 2007 08:03 PM

I especially like this one:

I'm a little reluctant to add to the wasteland that is this post and these comments, but here goes.

I'm familiar with the situation here. The deal was this: Derek was not a programmer; he was a musician. He learned some PHP and cobbled together the old CDBaby site by himself. It was good.

Then, he heard about Rails, and became infatuated with it. He proceeded to attempt a rolling rewrite of CDBaby's frontend and backend both (the backend is large, because of inter-label and digital distribution stuff) in Rails.

At this time, Derek had no experience with the following things:

* any language other than PHP
* systems integration and interoperability
* Rails
* object-orientation
* the MVC pattern
* managing a development team

Project fails. All right. As he has learned in #2, legacy compatibility trumps everything. Also, ship early and often.

As you can see in Derek's post about MySQL encodings, he's not always the clearest thinker. Even above he says that REST means POST-only destruction, which misses the point entirely.

His team was fine (mostly just Jeremy, until another developer was hired in the last months). Rails was fine. But there were a lot of things wrong with the project plan ("rewrite everything, eventually") and with the project leader, who was convinced he had found a silver bullet.

No framework saves you from your own inexperience.

Out.
wellwisher | September 23, 2007 01:47 AM 

So those of you following my blog know that after two years of being a full time Rubyist I’ve been tossed back into the cruel and unusual work of PHP development. I’ve really had to think long about my own development history when passing judgement on the current code base I am working with. What I’ve come to find is that the things I love about Ruby on Rails are logic, reason and proven best practices. What I dislike about PHP development is preference, opinion and tyranny.

“What do you mean by that?” What I mean is just this. Ruby on Rails has been at the forefront of emerging technologies and is consistently endorsed by well respected leaders in development technology like ThoughtWorks and countless innovators in the industry. It has introduced professional development techniques to the masses in ways that are unobtrusive and encourage thoughtful progressive improvement. What I like most of all – the things that have made it into Rails have been well thought out features that are supported by logic and reason NOT opinion.

What I’m finding in my return to PHP is that people just do things because they like it this way or that way. It’s a matter of personal preference. There is a complete lack of standards on how to best get something done. That usually means brute force wet (!DRY) code that does the job with the amount of style and grace as a bull in a china shop. I also think you see tyranny over reason in the PHP world because it’s a matter of preference. When you boil it down Ruby seems to be a philosophy whereas PHP is just a tool.

If you don’t care about efficiency stop reading now. Some readers might have caught that last bit “does the job” and said “well it does the job.” Yes it does the job for so long…then you change something…then it breaks something unintentionally. But you don’t know that it broke because you have no way of testing other than to put a person in front of a web browser or worse yet wait for a support ticket from your customer. Then you have no way of refactoring because everything is so fucking wet that your refactoring is actually rewriting from the ground up. If your grumbling – I told you to stop reading.

<!--[if IE]>
I hate you!
<![endif]-->