Derek Sivers of CDBaby kicks ass. He got a sophisticated and very very user-friendly, efficient, straightforward e-commerce system (including the back-end systems) written in PHP. Based on what I’ve read, he’s up there with Phil Greenspun in my opinion; that is, he’s among those who understand strategy and customer service and low-level technology and are able to build systems that don’t suck, resisting the temptation to be distracted by technological panaceas and fads. I may disagree with their individual technology decisions, but their higher-level thinking is excellent, so they’re definitely in the class of people who I’ll give the benefit of the doubt.
So when I read 7 reasons I switched back to PHP after 2 years on Rails I was a bit surprised, but not much. He’s experienced with PHP (he says he’s written 90,000 lines of code for CDBaby!), and has a huge installed base of code he wrote and understands intimately. He tried Rails, it didn’t work the way he wanted, and he went back to PHP. It was immediately obvious to him that this was what he should continue using.
The most shrill and arrogant among the Rails community have been rather unkind, partly due to this rather poorly written Slashdot headline that misrepresents what Derek says in his article.
I’m using Rails and I’m generally happy with it, though I have had to do some customization of the framework (mostly with pre-existing Rails plugins from like-minded developers) to suit my style. At this time I plan to continue using Rails for my project, and to keep using it in future projects.
But, I thought it would be instructive to summarize the arguments made by the folks slamming Derek in the comments to his article.
- Rails is the correct solution for CDBaby, regardless of what the founder//designer/lead programmer of CDBaby thinks.
- If you don’t agree with Rails’ design, you’re wrong, and you need to change your design if not your whole business to fit Rails.
- PHP is bad and can never result in good code. Conversely, Ruby is good and is always better than PHP.
- Objects are better than SQL and tables. Domain specific languages are great, as long as they’re written in Ruby; using SQL as a domain specific language for data manipulation and querying is not Ruby and therefore is a bad idea. Also, just because one person can code something in PHP in 2 months that runs on one server, instead of two people taking over two years to do it in Rails (which is notoriously hardware-hungry), doesn’t make PHP + SQL better. Because objects make you more productive.
- Just because you wrote a successful online store yourself from scratch, have an O’Reilly column, and then hired a Rails core team member who now works for the same company as most of the rest of the Rails core team including DHH (37Signals), doesn’t mean that you actually had people smart enough to rewrite your app in Rails. You need to prove to the world that what you wanted to do was impossible in Rails before we’ll give you permission to make technical decisions for yourself.
- If you don’t like Rails it must be because Rails is too good for you. Maybe instead of learning from years of real world experience running a business and writing the entire software suite for that business yourself, and hiring one of the best Rails developers in the world for your transition to a new architecture, you should have gone back and gotten a CS degree.
Since this is such an active flamewar with such sloppy readers (responding to the Slashdot headline’s misapprehension of what Derek wrote, instead of what he actually wrote), let me say this clearly:
The above listed points are not my opinions. They are summaries of opinions I find immature and silly.
(I’m assuming someone somewhere will read this post in anger and make themselves look foolish by arguing against these points as if I believed them anyway. I tried to warn ya…)
We can learn something from this. This same flamewar keeps appearing over and over and over, all over the internet, and before that, on BBSs and in print.
The simple fact of human mortality means that most of us are going to be learning and making mistakes that we imagine a wise, seasoned developer wouldn’t make. But that guy retired and is fishing, so it’s up to us to screw up and learn and hopefully do better next time.
For the last few thousand years, we’ve had the advantage of being able to read books, and get wisdom that way. But there are fads, and hyped books that seem to know it all. So you have to read a lot of books, and try a lot of contradictory ways of doing things, to get a mature enough perspective to make wise choices on future projects.
The point that is generally missed by everyone trying to do anything new to them, is that there’s a lot more out there that you don’t understand, and a lot of what you think is your brilliant new invention has been done before. The more you learn, the more humble you become as you learn that there are people WAY smarter that you are, and that there are people who have come before you who you will never catch up to.
In the case of web development, that means that there are people out there who disagree with you, and you might not actually know everything about everything like you think you do. Local experience and immersion in the problem they’re trying to solve makes them much better suited to solving their problem than some armchair quarterback. It’s tempting to fold your arms and feel smug about your quick dismissal of someone else who clearly isn’t as big a genius as you are, but the more certain you are of your own brilliance, the more likely it is that you’re just ignorant. (See also: Unskilled And Unaware Of It.)
In Derek’s case, he clearly jumped feet first into Rails and hired a rockstar developer, and then made the decision given a uniquely advantageous perspective that it just wasn’t working, after giving it a hell of a lot more time to pay off than I would have. (I’m not exactly sitting here scratching my head wondering “how could Derek have been so wrong?”)
What matters a lot more than choice of programming language is the ability to get the project done, meaning tested and correct and launched. Apparently for Derek, PHP is the way to get that done, and Rails ain’t.
Finally, consider the parallels between Derek in this case, and Phil Greenspun in his book (late 90′s). They both use SQL more than the “Objectistas” would like, which is to say, they use it directly and like it. They both use languages that are not the most fancy high level languages available, but they do completely understand how their application works, from UI all the way down to hardware performance, and they make integrated decisions that take business strategy and technological factors into consideration.
This is really critical to understand about why both of these guys are so smart: both of these people put aside dogma and made decisions that were all over the map, sometimes pragmatic and hackish, sometimes very rigorous and disciplined, depending on their assessment of the particular micro-issue they were addressing at the moment. They weren’t subscribing to any particular software development philosophy (Big Ball of Mud, XP, RUP, UML, Agile whatever, waterfall, etc.), nor did they just choose the most hyped architecture of the day and blindly stick with it, but freely mixed and matched whatever they thought was appropriate given their perspective on the situation.
In other words, they didn’t fall into the trap of thinking that there is One True Way to do everything. They improvised. They integrated their own experience and perspective with the wisdom of others, and made the decision that worked for them.
I hate to sound like a moral relativist, because I’m not. But as a practitioner, I’m definitely becoming more and more of a process relativist every day. One of the best ways to make a project fail is to try and force-fit an architecture and/or a methodology onto that project without customizing them to the particular details of the project. The best methodology is called “Roll Your Own.”
And so I leave you with this question, in the hope that it will help you with your current and future projects: Have you made any dogmatic decisions about your process or technology that are hurting your project?
Maybe it’s smarter at this point to keep doing what you’re already doing, but maybe there are some things that you could change. Try to keep your Mind Like Water, strong enough to cut through mountains but flexible enough to flow around obstacles, and making the decisions of which one to do based on the information that you and only you have.