On Derek Siver’s Return to PHP…
Sunday, 23 September 2007
Posted by austin in: Ruby, Technology, trackback
Derek Sivers, recently abandoned his CD Baby rewrite from PHP to Rails. This isn’t bad news for Rails or Ruby, nor is it good news for PHP. It’s good news for CD Baby. Anyone who reads it otherwise is missing the lesson.
There are plenty of reasons to dislike PHP (although all of my criticisms have to be aimed at PHP4 right now, as I haven’t done anything with PHP5), but it is a useful general purpose language. It has different philosophies than Ruby, and I think that in general it isn’t nearly as good a language as either Ruby or Python. But it is just fine for a lot of people and projects.
Derek’s planned migration to Rails was probably doomed from the beginning for several reasons:
- Derek chose the technology for the wrong reasons. He chose it partially based on the hype of Rails, but he envisioned it as a silver bullet that would magically make his application better just because it’s in Rails. Rails has advantages (not least of which is its language, Ruby), but it has drawbacks and weaknesses, too.
- Rails didn’t fit Derek’s application model for CD Baby, and Derek’s application model is more important than the technology to be used, since it represents a business he understands well. Rails requires that your application fits its model, not the other way around. As Derek says:
I hired one of the best Rails programmers…Jeremy [Kemper] 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.
- He ignored his existing experts for the new technology. Neither he nor his employees knew Ruby aside, perhaps, from playing around with it. This wasn’t a technology that was deemed to be appropriate from experience; this was a technology deemed appropriate by management (sorry Derek, you might still be getting your hands dirty with code, but you’re still management).
I’ve wanted to introduce Ruby in my workplace for several years, but aside from a number of compile-time helper scripts, it hasn’t been appropriate to do so. First, our product isn’t in Ruby’s sweet spot. Second, none of my co-workers know how to deal with it or its development environment. Even when Ruby is a superior choice, it’s hard to introduce it, because I’m the only Ruby expert at work.
- Derek approached the project as a whole-environment ground-up rewrite with a One Big Day deployment, without considering ways to phase it in over time. It’s almost always possible to find interface points where you can replace one broken piece at a time. Ultimately, this is what the Rails folks
wouldshould tell you anyway: replace one area at a time, each with a different codebase. Interface them as REST-ful services. Don’t make them depend on a single database schema.
Derek is wrong, though: language matters. A “better” language may not be the right choice for your environment, but its lessons will help you immensely. Without the Ruby and Rails experience, Derek would not have known to apply the lessons Ruby teaches to his PHP rewrite. I find that I write both C++ and C# with strong Ruby flavours these days. My boss, who has only used Ruby casually, has come to prefer the Ruby method naming convention (like_this) and a number of Rubyisms that I’ve introduced.
Ultimately, though, Derek’s Rails rewrite failed because he made a number of classic technology management mistakes. Not because of Ruby, Rails, or PHP. Because of management decisions made for the wrong reasons. Fortunately, he recognised this and was willing to reverse an expensive decision to fit his business better.
Comments
I’m sorry, but that’s just an asinine comment. Derek built a huge, many-million dollar business with thousands upon thousands of users largely with code he wrote by himself. I’d say that makes him an okay programmer, far better than ones that have no business sense.
Careless, disdainful sideswipes like this exemplify the childish elitism rampant in much of the Ruby community.
It’s neither asinine nor “childish elitism”. I admire Derek’s ability to admit that he made a mistake and to fix it. I don’t care that it was fixed in PHP as opposed to Ruby.
When Derek made the decision to switch to Ruby over PHP he did it as a PHB impressed with hype. When Derek made the decision to switch back, he did it as a business owner who realized he’d made a PHB-style mistake.
The moment you make a technology decision that doesn’t consider the people who have to maintain it — including yourself — you are acting like PHB management.
An example: I would much rather write my team’s auto-test environment in Ruby. It’s easier to maintain, easier to develop, and would be easier to extend than C#. The moment I do that, though, I force everyone else on the team to learn Ruby before they can do anything related to providing automated tests. Because I recognise this, we wrote the auto-test environment in C# because it’s one less technology they have to learn.
We have other pieces of code that have been written in Ruby because the value-add of Ruby outweighed the learning curve, but those are specialized.