Getting Rails Backwards.
ryan / Sun, 25 Jun 2006 03:38:00 GMT
Getting Rails backwards
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:
- More robust data integration (for poorly designed databases)
- “Better” CRUD scaffolding (so it can have more whiz-bang AJAX)
- 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.
Subscribe
Really good points. I’m an optimist, and possibly a bit blind/gullible (maybe just too into myself), but I haven’t had the same experience here at RailsConf of bumping up against people who don’t “Get” Rails.
Listening to DHH’s talk I got two separate things that are going on – 1) the overarching goal of making the framework disappear until you truly only work on the business rules that are interesting (echoing Fowler’s keynote) 2) In order to get there, there is a bit of muck we need to get through – things like responds.to…
I disagree about the scaffolding (although maybe it’s the term ‘scaffolding’ which needs to be corrected). Lets say I create, via a migration, information about the fields of a model. I say that I have a table called stock and that stock table has a field – code (which is 15 chars and can’t be null).
I don’t necessarily want to create scaffolding but what I do want is (for example) the framework to understand that the code field can’t be blank and can’t be longer than 15 chars without me having to put in validation. I don’t want to have to put the text field on a form and say specifically that the field is 15 chars and no more. Why do I have to repeat what I’ve already defined at the db (or, if you prefer, migration) level? When the client says that code needs to accomodate 20 chars why do I have to write a migration and then tell my model to allow that in a validation and then tell my view to increase the size of that field on a form?
It’s not DRY, it’s tedious crap that takes up a lot of my time and it’s wrong.
“At Lovetastic, we’re writing a complex migration script to adapt all our old data and schemas to conform to Rails conventions. “
See the thing is, the fact that you think it’s that simple implies that you don’t understand the problem. Many big companies can’t just redefine their schema. They have hundreds of apps running against those schema and to ask them to rewrite hundreds of apps isn’t feasible. But, replacing one app or being able to write new apps against those existing schemas is feasible.
It comes down to whether or not you care if Rails finds it’s way into the enterprise. Does the success of Rails depend on that happening? No.
I can agree with DHH when he says he doesn’t want to do what DaveT wants, but, honestly, adding some support for foreign composite keys would not kill rails and would not degrade the beauty of it. Can you tell me exactly how something like “composite_key :state, :city” as a declaration in a model definition would destroy the beauty? If you can, please tell me.
I like Rails and I’m fine with the direction DHH wants to go. It’s his choice to make. If someone wants to do things differently, then they can and should fork the code. That’s the beauty of open source and I’m all for that. I can’t see why anyone wouldnt’ be.
Rails is what it is and should stay true to what it is… To become “enterprisey” would be to completely turn its back on what it is good at.
I agree with Mr. Thomas… Corporations are not going to run to or even explore Rails unless it is “enterprisey”. But guess what? That is a huge reason why Rails is so popular.
If Microsoft had released Rails, how popular would it have been among the crowd that loves it so much?
Mr. Thomas should not be pushing such rubbish!
Will Rails somehow change the direction corporations have been taking since their inception? No Way.
From day one, who embraced PHP? Young professionals.
From day one, who embraced Java? Universities and Corporations.
How many people today would call PHP “enterprisey”? Ok… quite a few, but only because it can scale.
“Rails will only be a success if it persuades the programming culture in large organizations to adapt to its opinionated way of doing things…” Rails is successful and not a chance. If large corps. move to Rails then something horrible must have gone wrong.
Scott: Well, maybe those people shouldn’t be rewriting their apps in Rails without going through some hoops. Rails is not a solution for everyone… and the core team knows this. They want to keep Rails a really great solution for the 90% and let the 10% go through lots of hoops to get it to work for them. If you want something that is equally painful for everyone, go use Java.
And if it turns out that 90% of people are using that composite keys plugin that some enterprise ready fellow made, I’m sure it would make it into core.
Hi Scott: The point here is we’re talking about Rails core. I’m not opposed to people supporting their composite keys, they should just write their own plugins for them and release them online so all their enterprise buddies can use them. It shouldn’t be part of Rails core code. As DHH said in his keynote, the idea is to make it hard to do the wrong thing, not impossible. My point is that this is what makes Rails unique: not because of technical achievements, but because the framework out of its way to try to compel you to be a good programmer. If you want to solve problems that grow out of your own complexity, they’ll take you 80% there and you can do the rest.
:)
Well… I’m in line with Scott in #5 here. I too love Rails, and I’m doing many projects with it. But in some projects it’s simply impossible to use for the exact “enterprisey” reasons that scott mentions. Support for composite primary keys won’t dilute the rails core – if you don’t use it, simply – well – DON’T USE IT. Like it’s possible to override table pluralization and pluralization in general in the current Rails.
Kludging up your exisiting schema to accomodate Rails is a bit backwards, to say the least. Sure, if you’re building a new app from scratch, go the “Rails way”. I always do. But in many, many cases, there are going to be other applications needing access to that same data, and then Rails simply cancels itself out by not having better “weird schema” support.
A plugin supporting this type of behavior might be a good idea – but I don’t really see any reason why it can’t be added to the Rails core.
About composite keys: I have written an ORM layer for commercial desktop application which had general (composite) keys in mind, though limited to integer values. I can tell you that the difference between single unique integer key and composite multi-column non-integer key is HUGE. It takes 100 times as much code for the core developer AND user developer, and introduces lots of potential bugs. It is not worth it.
It is the same as specifying the interface and everything in XML. It is possible, but you do not want to do it. This is main point of Rails. If you want verbose, ugly, buggy implementation, just use Java.
I think perhaps I failed to make my point.
I don’t myself want composite keys and the like.
But what I do want is to share the joy. Yes, we can say to people “what you’re doing is wrong. Fix your ways and you can play with us.” That’s pure. It’s radical. It’s fun.
But I’d much rather find ways of improving these peoples lives by letting them play. I explicitly said I don’t want these things as part of core. But I do want them available so I can throw a lifeline to people drowning in corporate development.
Expecting GE to change its database schema because we say “it won’t work with Rails” is just plain dumb. So, as a stop gap, I think we should find other ways of letting them work with us. Then, once they’re in the fold, they can start to promulage the Rails way back into their organization.
Hi Dave,
Yes, perhaps my surprise at what you said was because I simply misunderstood your overriding point. It seems much more reasonable when you put it this way:
“we can say to people ‘what you’re doing is wrong. Fix your ways and you can play with us.’ That’s pure. It’s radical. It’s fun.”
As DHH said, it wasn’t so much the content of your keynote that seemed off, as the seeming tone that the most important challenges to Rails were enterprise adoption.
I was there at your studio in Chicago (which was wonderful by the way), so I know that you deal a lot with people sent by their bosses to learn Rails who are stressing about legacy schemas, etc. I do think there is something to be said for being able to bring these people to the Rails way of doing things.
These are the clever people who might someday be submitting patches to make Rails better, but they won’t be doing that if they’re not using Rails in the first place.
So, although I’m still not sure that getting GE to use Rails is the most pressing challenge to making it a better framework, it still seems like a worthy ancillary goal to make plugins available for them.
Perhaps it was the early hour, but for some reason, your saying that you wanted these changes to be plugins and not part of core completely escaped me and those sitting at my table at RailsConf.
So perhaps our goal should just be keeping Rails opinionated, but still friendly to outsiders. :)
Just came over from loudthinking. Halleluja, Ryan!
I’m having a bit of trouble understanding why some of you think composite keys are Enterprise-level stuff or are somehow “bad practice.” There are times, even in very simple databases, when composite keys are absolutely the right thing to do, from a database design perspective. They’re not wrong at all. In fact, there are times when a single auto-increment column is very bad database design.
Describing the relationships and nature of data is the whole point of database design. Intentionally limiting the design decisions to an extremely (I’d say excessively) simple subset of standard database design principles is…silly.