Wednesday, September 26, 2007

Derek Sivers' Switching Back To PHP Isn't Even About Languages

I bookmarked Derek Sivers' recent blog post giving 7 reasons he switched back to PHP from Rails. Turns out I wasn't alone: 1,050 other people on bookmarked it as well. Since then people have been getting all worked up about it on Ruby discussion lists. Obviously, if over a thousand people bookmark something, and spend time discussing it, then people think it's a big deal. But people are wrong. The post didn't really even have 7 reasons. It just had one:


That's about it. If you're looking for all killer, no filler, Sivers' article won't deliver. There's one important point - integration is hard - and one cool insight - "languages are like girlfriends, they're better because you are better" - and there's also a whole bunch of extra words.

Last year Chad Fowler wrote about the Big Rewrite and why it always fails.

You’ve seen the videos, the weblog posts and the hype, and you’ve decided you’re going to re-implement your product in Rails (or Java, or .NET, or Erlang, etc.).

Beware. This is a longer, harder, more failure-prone path than you expect.

Throughout my career in software development, I’ve been involved in Big Rewrite after Big Rewrite...In many cases, these Big Rewrite projects have resulted in unhappy customers, political battles, missed deadlines, and sometimes complete failure to deliver. In all cases, the projects were considerably harder than the projects’ initiators ever thought they would be.

This is not a technology problem. It’s not at all Rails-specific, but being in the limelight these days, Rails implementations are both very likely to happen and very risky right now.

This is exactly what happened to Sivers. He attempted a big rewrite in Rails and later abandoned it for an incremental rewrite in PHP. The Big Rewrite doesn't work. Incremental rewrites do work. But that doesn't say anything about Rails or PHP. You can fail with Rails and succeed with PHP for reasons that have nothing to do with either language.

For some reason, few people in programming study what other programmers have done before, and so, given that the majority of us don't study history, the majority of us are doomed to repeat it. That's fine. If you don't want to study history, go ahead and repeat it. But some of us do study the history of what we do, and some of us have already learned these lessons the hard way.

Personally, I think this failure to study history is a serious shortcoming.

When you think about the reams of money companies go through every time an inexperienced programmer or manager learns this lesson the hard way, and you put an actual price tag on that experience, and then you compare it with the price of a freaking book, you kind of have to wonder what's going on with people in our industry.

Anyway. For what it's worth, the next few days are going to be a good time to write code (or go to conferences!) but a terrible time to read e-mail lists and blogs. There's going to be a lot of discussion about what Sivers' post "means." I'm as guilty as anyone else of responding to the hot topic of the day, but if I see any more discussion of this post, I'm just going to read some programming history on Wikipedia (or even - gasp! - write some code). My suggestion: the moral of the story is that many programmers have a shallow and irrelevant fixation on languages, and don't spend nearly enough time learning the history of what we do.

Update: Raganwald noticed this too.


  1. More than once, I've thought about starting an interview with "Tell me about a good programming or software book you've read" and DYHAQFMing them if they don't have an answer.

  2. @Joe:

    You could also ask if they've read any non-fiction book related to technology or engineering and what they learned from it. "The Myth of the Machine" series by Mumford has some good concepts every developer could learn from. For example, in "Technics and Civilization" you learn that it's how we think that matters. Technology can change our habits, but it may not measurably improve the situation if the people using it don't understand what it's good for. A great example is VCRs. Most people who bought them never used them to record much of anything, because they didn't understand how that function worked (most clocks on them flashed "12:00" all the time). They just used it to play movies.

    Another example could be "Understanding Media", by McLuhan.

    Anything that expands practitioners' understanding of how technology is really used would help.

    All project managers should have at least heard of "The Mythical Man Month". If they haven't, watch out!

  3. Right on, Giles. I read the article the other day, saw the hundreds of comments, and thought to myself, "why are all these people even bothering to comment on this"? The summary I came away with was "We ended up going back to PHP because we weren't ready to leave PHP". Somewhat of a tautology, but that's humans for you.

    (as an aside, I do think that in some situations [big technology shift + circumstances allowing it to happen without screwing up the existing system], the "big rewrite" actually can work--I'm nearing the completion of one right now--but perhaps in Sivers' case, their PHP technology isn't bad enough to warrant a change to Rails)


Note: Only a member of this blog may post a comment.