[Amusingly, this post spend a significant amount of time as the #1 post on the Reddit home page when I wrote it. Huzah.]

I respect Dave Thomas tremendously, which is why I was all the more baffled by his keynote at RailsConf yesterday.

He began by invoking German mathemetician David Hilbert’s speech at the International Congress of Mathemeticians in 1900 in Paris. He said he wanted to challenge the Rails community, like Hilbert challenged mathemeticians, to solve some fundamental remaining problems in our domain of work.

Hilbert identified twenty-three. Dave, famously fond of elegant solutions, opted for just three:

1. More robust data integration (for poorly designed databases)
2. “Better” CRUD scaffolding (so it can have more whiz-bang AJAX)
3. Making it possible for developers not to have to think about deployment (and push that problem onto a “sysadmin”)

The tacit point behind all these proposals is Dave’s observation that Rails isn’t flowchart-ready, as it were: it isn’t sufficiently enterprisey. He feels that if Rails doesn’t adapt itself to be more welcoming to the culture of large organizations, it will never see its true potential. Dave thinks the secret to success for Rails is becoming an “insider” phenomenon.

I think Dave has got it precisely backwards. Rails will only be a success if it persuades the programming culture in large organizations to adapt to its opinionated way of doing things, not the other way round. It’s a question of how you define success: are we just interested in adoption numbers, or are we interested in giving ourselves the most joyful, aesthetically pleasing framework humanly possible? Put another way, do we want a side-effect of Rails to be bringing joy to enterprise programming, or do we want enterprises to bring their bad methodologies to Rails? I think I’d prefer the former.

In his RailsConf keynote later that day, Paul Graham extolled the virtues of being an outsider, which is not a very enterprise-ready thing to be. He also warned against “the need to seem serious.” He said, " “Using Ruby on Rails is marginalizing yourself – welcome to my world!”

DHH discussed this same idea when contemplating whether the Rails community should want the framework to become mainstream. His conclusion was that reaching the mainstream meant reaching people who just don’t care.

We ought not to be interested in just making life easier for people who don’t care; we ought to be worred about how to make people care in the first place. The way to do that is to entice them with a better way of doing things, not by embracing their worse way of doing things. To do that would be to miss the point of Rails in the first place.

What makes Rails special

What makes Rails special isn’t that it’s a thing for making websites more easily; that is just an ancillary side-effect of what makes Rails a truly stunning achievement. What so many people seem to be missing here at RailsConf is that the achievements of Rails aren’t primarily technical; they are aesthetic.

DHH rightly calls Rails opinionated software. DHH understands that the key to productivity as a programmer is happiness. Rails imposes well-thought-out conventions in order to create a framework that is simple and that results in beautiful code and elegant solutions.

Using Rails is joyful precisely because the core team has had the restraint to say no by default. The core team have maintained DHH’s singular vision for convention over configuration and simplicity and in so doing has bought a tremendous amount of productivity, beauty, and happiness in the process. As Thucydides reminds us, “of all manifestations of power, restraint impresses men most.”

In spite of all this, nearly every suggestion in Dave Thomas’s keynote was about adding complexity in order to accommodate people who don’t care about adapting their programming to our passionate, opinionated framework.

Let’s take a look at each point in turn.

Data Integration

Dave expressed his frustration with the lack of easy support in Rails for legacy schema that use squirrely forms and things like composite primary keys and things that might be found in “enterprise” databases.

At Lovetastic, we’re writing a complex migration script to adapt all our old data and schemas to comform to Rails conventions. We’re going to be inserting the resulting data and adapted schemas via SQL into the new Rails database. Sure, this takes a bit of work, but we believe that what Rails conventions buy us is worth the cost of a little work. We get the joy of expected behavior, convention, beauty. I’m glad that I have the Rails conventions to have to conform to, because they make me a more disciplined database designer. This is how it should be. I want to be prodded into doing things right, which is what Rails intentionally tries to make us do.

“Better” CRUD Scaffolding

Dave asserted that current scaffolding is very “Web 1.0” and we should try to add AJAX to scaffolded forms and work on more sophisticated scaffolding.

Yesterday in her talk Overcoming Scaffolding Addiction, Amy Hoy pointed out that, although Dave Thomas was her hero, she felt that, “we don’t need better scaffolding; that would be counterproductive.” (As it happens Amy Hoy is my hero. She’s done a great job of introducing Rails intelligibly to neophytes without diluting or undermining the opinions behind the framework, and I learned a lot from her blog starting out.)

In some ways, I wish scaffolding could be completely removed from the framework. It’s a very useful tool and it makes it easier for to introduce Rails to (and impress) people who come from JAVA/PHP/etc. However, it’s often used in introducing Rails to other people, so some people assume scaffolding is Rails. For example, most of us were introduced to Rails through DHH’s 15-minute weblog video, which is basically a demo of scaffolding.

But scaffolding is not and never was intended to be central the the Rails development process. It’s literally a way to save you some typing when getting your application up and going, so you can start poking around with data early on. It’s not supposed to build the application for you. Only you know your business logic, and scaffolding isn’t going to help you with it.

Adding finishing touches like AJAX to scaffolding will scarcely improve Rails workflow; it would only be a way of impressing people who Don’t Care.

Deployment

The third obstacle to enterprise adoption that Dave pointed out was that Rails currently forces developers to think about deployment. He suggested that Rails developers should be able to push deployment concerns onto someone else in the organization (presumably non-programmer “sysadmins”).

Now, as I discuss below, Rails deployment could certainly use some work, but the notion of separating concerns so cleanly in a web team isn’t probably that advisable. Developers should be familiar with the systems their apps will be deploying on, and sysadmins should know about the application they are deploying. Equally, you’ll probably find that development is more functional in small teams where there is no distinction made between sysadmins, developers, and testers. The guys at 37signals are very articulate on this point (as with most points) in their Getting Real book

Dave Thomas was right on two important points

This all being said, Dave did get two things spot-on.

• Elimination of duplication on migrations

As it is, Rails violates the DRY principle by forcing developers to define model information in two places: both in database (through foreign keys, default values, etc.) and then again in the models.

In his own keynote, DHH said that he agrees with the need for an ActiveModel, and it seems all but certain that this duplication will be eliminated with time.

• Deployment is still too complicated on Rails.

The developments of gems and packages to make Rails deployment easier will come with time, but right now it’s always a complicated decision about what to use, and how to do it. Also, there seems to be a paucity of people who have actually deployed real production Rails apps (beyond Typo) on the web, so it’s hard to find good tutorials.

RailsConf surprises

What has been most surprising for me at RailsConf has been the extent to which so many people just don’t get what makes Rails Rails. The Rails framework is not just a new toy; it’s a radical new philosophy of web development — and of programming in general.

That’s why I’ve cringed when I’ve heard so many people talking about more robust scaffolding, why premature optimization is a good thing, and that Rails is just some new kind of AJAX-making platform.

In his keynote today, DHH reminded us that constraints are liberating. Rails is about embracing constraints and listening to the angel programmer on one shoulder rather the devil programmer on the other. I hope he will prevail in convincing all the putative adherents of Rails here at RailsConf that this is where the achievements of Rails lie — and that continued success won’t just mean widespread enterprise adoption of the technology, but widespread adoption of the Rails philosophy.