I have been reading a number of posts around the web about Derek Sivers of CD Baby dumping Ruby on Rails to return to PHP. I am sure just about every Ruby enthusiast has read the post over on the O’Reilly Ruby blog.
In case you missed it the post is about how CD Baby spent the last two years converting their PHP-based web application to Ruby on Rails only to have the project fail and Derek going back to PHP and doing it himself in two months. Here is an except from the O’Reilly web site:
INTRO / BACKGROUND:
Back in January 2005, I announced on the O’Reilly blog that I was going to completely scrap over 100,000 lines of messy PHP code in my existing CD Baby (cdbaby.com) website, and rewrite the entire thing in Rails, from scratch.
I hired one of the best Rails programmers in the world (Jeremy Kemper aka bitsweat), and we set off on this huge task with intensity. The first few months showed good progress, and Jeremy could not have been more amazing, twisting the deep inner guts of Rails to make it do things it was never intended to do.
But at every step, it seemed our needs clashed with Rails’ preferences. (Like trying to turn a train into a boat. It’s do-able with a lot of glue. But it’s damn hard. And certainly makes you ask why you’re really doing this.)
Two years (!) later, after various setbacks, we were less than halfway done.* (To be fair to Jeremy’s mad skillz: many setbacks were because of tech emergencies that pulled our attention to other internal projects that were not the rewrite itself.) The entire music distribution world had changed, and we were still working on the same goddamn rewrite. I said fuckit, and we abandoned the Rails rewrite. Jeremy took a job with 37 Signals, and that was that.
I didn’t abandon the rewrite IDEA, though. I just asked myself one important question:
“Is there anything Rails can do, that PHP CAN’T do?”
The answer is no.
I threw away 2 years of Rails code, and opened a new empty Subversion respository.
Then in a mere TWO MONTHS, by myself, not even telling anyone I was doing this, using nothing but vi, and no frameworks, I rewrote CD Baby from scratch in PHP. Done! Launched! And it works amazingly well.
Projects fail and this won’t be the last one. What I find most interesting is not that the project failed, failed using Rails or even went back to PHP, but the number of comments from Derek’s post, 333 as of the time of this writing. What amazes me beyond the number of comments but the number of comments by people taking the time to piss and moan about either how PHP sucks, the CD Baby site sucks or how Rails sucks and Derek should have known better.
This is not the first set of comments of this type I have seen, it shows a common pattern. People spend their time becoming angry and venting to someone because they don’t like what they are reading. This is obviously counterproductive, immature and makes the commenter lack credibility. The shear number of comments to Derek’s posts reveals the true passion people have for a technology and points out how people often lack communications skills to adequately describe their bias to their technology. The outbursts we see in posts mostly shows a defensive response to something they are taking as a personal attack.
You can see what I mean from a few of the comments:
Your website looks like a spam site.
Anonymous | September 22, 2007 07:11 PM
Haha at the Rail Kiddies…
PHP is a super slow language that not even ruby can beat for performance.
Why bother to post at all if just to attack? I always find this interesting, many people take time out of their day just to post a negative comment instead of something constructive and useful. Not all comments are negative and some are very useful, still showing a bias toward a language. I think people who can successfully communicate why their language is better in solid technical reasons from a background of real experience really give value to a post. Why waste time posting a comment it is not going to be constructive?
Our bias sometimes prevents us from adding value to our profession, whether it be a blog comment or even at our jobs. I have seen people get incredibly agree when second-guessed in a meeting about a technology decision they have made. It makes them look very bad to their peers and bosses.
I like to step back and think before reacting. Sure, developers take pride in the technology they have chosen and it is easy to be reactionary to be put on the spot and asked to justify our bias.
I try to follow some rules of thumb:
- Think out-of-the-box – don’t just say your technology is “the” one to use always, because that is never the case. Just because it is the technology we know it doesn’t mean it is the best one in this case so know when to have an open mind.
- Know what you don’t know – we don’t know everything, don’t try to come across as a know-it-all, be willing to listen to others when the technology is something you are not familiar with
- Leverage what you do know – be able to effectively communicate why your technology is best for the job. Do it in a calm and intelligent way.
- Keep in mind the real goal, solving business problems. When all is said and done this is what we are paid to do so just do it. If your technology is not best for this particular business case then accept it and move on.
Here is another post on a different blog that shows a similar attack on Ruby on Rails by someone who just met Erlang and decided it was “the” technology for him. Instead of a good list of technical reasons against Rails and how Erlang solves problems better, the author just attacks Rails and the Rails community with little technical reasons for anything. This is another great example of a bias without thought and without real experience. The post did receive a fair amount of comments pointing out holes in the anti-Rails arguments.
So, if you are going to comment on blogs, make the comments positive and have it add value to the conversation. You will look more authoritative and will spark better quality comments from other readers.