Monday, July 23, 2007

The Business Advantage of Rails

It's important to realize that the greatest strength of Rails is not what but who. Rails places huge emphasis on making programmers happy. What makes programmers happy? Elegant systems which make them productive and take tiresome, tedious bullshit out of their daily lives. People who value that are the people you want to hire.

The technology you choose will shape the people you hire, and the people you hire will shape your culture. People who get tiresome, tedious bullshit out of their way forever are great people to work with. Conversely, tolerating tiresome, tedious bullshit without ever fixing it is absolutely not a character trait you want your hiring process to be biased in favor of. Think about the effect that this decision has on your corporate culture. You want to bias your corporate culture against wasting time, and against putting up with problems that could be solved gracefully and easily. It is infinitely easier to bias your organization's culture in favor of these traits by hiring Rails programmers than it is to filter Java programmers for those same traits (for example).

Joel Spolsky's hiring rule is "Smart and Gets Things Done". The implicit hiring rule if you're hiring a Rails programmer is "Smart, Gets Things Done, and Is Happy." This is very very much better, as a hiring rule. The reasons are utterly simple. Interacting with other people is a huge part of working. Corporate politics are inevitable, because politics is really just the art of getting people to agree on what they're going to do. But even though corporate politics are inevitable, dysfunctional corporate politics are not. The politics of happy people are infinitely preferable to the politics of unhappy people.

It sounds touchy-feely but "Is Happy" should be a hiring priority right up there with "Smart" and "Gets Things Done", and Rails is one way to make that happen. Programmer happiness is a guiding design principle in both Ruby and Rails. One reason people work with Rails is because they value their own happiness. If everybody you hire prioritizes their own happiness, the corporate culture which results will probably be a healthy one. If you want to get something done, give it to the busiest person you know; if you want the process to be fun, make sure the busiest person you know is also somebody very happy.


  1. Interesting post, but I will not say that "programmer happiness" is a "business" goal, unless maybe you are in the programming business ;o)

  2. Ah yes, clearly the measure of complexity is how many pages you can write about something. Never mind that Hibernate has entire books written on it and Struts and JSF each have entire books written on them... Many entire books... Many longer than 700 pages... While I don't like being a fanboy much, that's a very bad measurement there.

  3. @franck - but I am in the programming business! every programmer is, by definition. I think you can actually generalize this out to any kind of knowledge work. what makes accountants happy? clean books. if accounting processes at Enron had been optimized for accountant happiness, Enron would have been a very different company.

    this whole line of reasoning assumes honest people who like to work, but I think that if you start with that assumption, it can become a self-fulfilling prophesy.

  4. @shadowfiend - I had to delete that post. the bit about Rails being nothing but hype was rude, and I have a zero tolerance policy about that. I'm extracting the bit you responded to:

    The RoR book from Thomas & Heinemeier Hansson has approx 700 pages. 3 chapters are devoted to ActiveRecord alone. This complexity doesn't make me happy.

    This comment is like a complaint that snowboarding isn't fun because to learn how you have to fall down in the snow. Obviously there's always a tradeoff between the hard work to learn how to do something and the pleasure of actually doing it.

    I think the original poster will find, if they keep learning Rails, that the actual experience of coding Rails and working with it is a lot of fun.

    I don't mean that Rails is effortless and will enable you to make money without actually working. I just mean that the work you do is very satisfying, and more satisfying than the work you would do to get identical results with different systems.

    Obviously, however, I'm going to have to rethink my thesis, because it's partly untrue. Rails makes diligent programmers happy, but it also attracts people who complain about hard work, and worse yet, the "hard work" of learning the most newbie-friendly serious Web framework there is.

  5. You said "Rails makes programmers happy". Well, I'm a programmer and, it does not make me happy. I don't like working in Rails at all. And I think I have give it a fair chance.

    I like working in Java, Python, and even C. But not Rails. I can't really put my finger on what exactly I don't like about Rails. I just don't enjoy developing in it as much as I do in the other platforms I listed.

  6. Maybe I just drank too much Kool-Aid.

  7. I agree with hiring happy developers, and keeping them that way with technology that doesn't suck.

    Re: Ruby

    Even though I don't like the title of this guy's post (he refers to your post), I think he makes a good point that even in Ruby the complexity can get out of hand, and that a good refactoring tool would be nice. Does such a beast exist? As I read his post I had the thought that Squeak/Smalltalk has a refactoring browser, so you can refactor in it. In terms of Ruby being like Smalltalk, it would be nice if Ruby was more like Smalltalk in more than just language syntax.

  8. I think you're conflating frameworks and languages here. What about developers who choose to use Ruby *without Rails*?

    It's really far more about the framework than the language, which is why it's unfair to say "hiring for Rails programmers versus Java programmers".


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