A few weekends ago, in Chicago, Ted Neward asked me an interesting question. I had a kind of lame, generic response at the time; it took me a few hours to really think things through and work out what I really think about the issue. I’m finally getting around to blogging about it.
The occasion was a No Fluff, Just Stuff speakers’ panel. As is usual these days, there was a question about Rails: “What do you think it’ll take for Rails to hit the mainstream,” if I recall correctly. I answered that Rails is already on a path that will lead to very widespread use, but that it won’t necessarily be smooth. I predicted that the next year would see a highly publicized “Rails failure,” caused not by Rails itself but by a company that tried to do Rails with the wrong team.
That was when Ted, who was moderating the panel, asked his question. “What is the right team, Glenn? Does it have to have Dave Thomas on it?” Of course, Ted was deliberately overstating the question to be provocative; that’s part of a moderator’s job. But there’s a serious question there. If you want to experience the benefits that are being claimed for Rails, what kind of team should you have?
If I had to explain Rails’ secret sauce in one short sentence it would be this one: Rails makes it easy to do the right thing. “The right thing” there means the kind of basic software design and development practices that are widely known, but not so widely practiced because the typical team isn’t very disciplined. Things like
- Writing clean, expressive code
- Avoiding duplication
- Keeping responsibility well defined (in layers, components, classes, and methods)
- Testing thoroughly
- Aggressively employing automation for repetitive tasks
Others might see different things behind Rails’ success, but for me, making it easy to do the right thing is crucial. Things that take a lot of discipline in other languages and frameworks become much easier in Rails. In some cases they’re so easy that they’re actually the path of least resistance. In others they still take discipline, but the drudgery has been reduced dramatically.
The key to building a Rails team is to choose a team that’s prepared to exploit that characteristic.
A good Rails team will consist of programmers who know what they should be doing, and usually have the discipline to do it. They have a good, solid grounding in software design principles and development practices, and a good track record of sticking to them on real projects. Such a team will fall right into the Rails way of doing things, seeing an environment where many of the barriers and obstacles fall away and they can do good work with less effort. This kind of team will see big productivity increases once they get the hang of Rails.
If you feel like gambling, you might not do too badly with some less skilled teams: teams that understand what the right thing is, but aren’t quite disciplined enough to do it consistently. That kind of team may find that, with Rails making the job easy for them, they can be a little more disciplined and start doing much better work. (Just making the right thing easier wouldn’t be enough, but Rails also exploits the No Broken Windows effect: the skeleton application Rails gives you to start out with is in such good shape that it feels wrong to mess it up.) Again, it’s not a sure bet, and you’ll be much better off with a team that’s already strong.
The wrong Rails team is one that doesn’t understand those principles and practices. The fact that Rails makes things easy won’t be enough. In my experience, such teams expend amazing effort and ingenuity to do the wrong thing.
(On the other end of the spectrum, there’s a fourth kind of team that is the ideal Rails team. The truly great Rails team will understand not only what Rails gives them but how it does it, and the team won’t merely benefit from Rails but will build on it, carrying Rails’ design philosophies and techniques into the domain of the application being built. Expect these teams to create their own Ruby domain-specific constructs, extending Rails to meet their own needs and amplifying their own productivity through the course of the project.)
So (you might ask) how are Rails teams any different from any other project teams? The answer is that they’re not. An experienced, skilled team will, in all likelihood, find ways to be successful. An inexperienced one can find many ways to fail. Somewhere in the middle are the teams where each project is a gamble: they might fail, or succeed modestly, or even succeed spectacularly, but it’s very hard to predict the outcome. No tool, language, or framework—not even Rails, which I think is the best thing going—will change that. When you pick up a powerful tool, it doesn’t eliminate your weaknesses; rather, it amplifies whatever characteristics you bring to it, strengths and weaknesses alike.
Rails gives a team some great tools for success. But the team has to understand those tools and be prepared to exploit them.
Same as it ever was.
I have to admit that my first reaction to Ted Neward’s blog about Rails was the same as Dion’s and Justin’s: “Ted’s missing the point.” But his followup has mostly changed my mind. Ted’s still skeptical, which is a good thing, but what he thinks he sees in Rails, and what he’s looking for, is (to my mind) the right thing, and my belief is that he’ll find it there.
Ted writes: “Look, guys, at the end of the day, if Rails is about Ruby and the things that a scripting language can do that a compiled, statically-typed language can’t, then Rails definitely has a place in the world and I’ll take the time to learn it.” My position is that that’s precisely what Rails is about. Sure, some of the lessons that Rails teaches can be carried across to statically-typed languages just fine, but some of the most important ones simply won’t translate. Rails is a testament to the power of dynamic languages in general, and of Ruby in particular.
Here’s one example: it’s a mistake Ted did make in his first blog, and it’s a mistake others make as well. “I mean, I see a bunch of intelligent code-generation,” Ted wrote, and if you’re coming from a static language background it’s easy to look at Rails’ scaffolding support and default views and think that’s what you’re seeing. I thought so, too. If that’s what the scaffolds are, they aren’t too impressive—partly because that’s easy to do, but mostly because generated code like that eventually becomes a burden. Most of us have seen code generation tools before, and they’re great for getting started, but when you move beyond what the generated code will do for you you’re in a world of hurt, often having to throw away what’s built into the framework and supply your own versions of everything.
But Rails isn’t doing “intelligent code-generation”—unless what you mean by that is that it’s doing the least possible code generation. Crack open those scaffolds and look inside. They’re almost empty! Usually they’re just trivial class definitions, with no methods or fields. All of the behavior comes at runtime, through inherited reflective logic. Rails is generating structure, not behavior, and that turns out to be a huge win. Ruby makes that possible, partly through its rich support for runtime reflection, but mostly because its dynamic, open nature makes it a breeze to fill in those empty spaces incrementally, overriding and extending little by little the default behavior that’s built into the framework.
And that’s just one example of how a dynamic language makes Rails possible, and why some of Rails’ goodness is easy for we static-language types to miss at first glance.
What’s Rails about?
- It’s about Ruby and the things that a scripting language can do that a compiled, statically-typed language can’t.
- It’s about confirming some of the earliest thinking about frameworks: that they should be extracted from well-designed applications, rather than being designed on their own.
- It’s about demonstrating the fundamental importance of the DRY principle for software design. (Bruce Eckel calls it “the most fundamental concept in computing.”)
- Oh … and it’s about bringing the pendulum back away from the layers-upon-layers default approach in Java projects.
When Mike Clark was writing Pragmatic Project Automation, he and I conspired about a few things. A biggie was build scripts—in particular, the expressiveness and power thereof. We persuaded James Davidson to publicly admit that the choice of an XML format was … well, not a mistake exactly, but ultimately a limiting strategy. And we wanted to demonstrate the usefulness of having a real programming language at your disposal in a build script. A lot of this came from our interest in Ruby and our use of Rake, but in the context of a Java-focused book Mike decided to demonstrate by using Groovy to script Ant. That was cool, but it just touched the surface. Since it wasn’t really the main topic of the book, Mike wisely kept it short.
Today, Martin Fowler blogged an excellent article about the strengths of using Rake. Martin gives it the full treatment, explaining Rake, how it’s similar to both Make and Ant, and how it goes beyond both of those older tools. He demonstrates in several ways how powerful it is to have all of Ruby available in build scripts.
My favorite line: “After all, until we tried it I thought XML would be a good syntax for build files.”
(Oh, and I’ll add to Jim’s request for recordings or podcasts of Why’s performance. I’m particularly interested in a recording of “Setup and Install.rb” from Wednesday night’s FOSCON show.)
I’m back from OSCON 2005, and it was definitely a watershed event for Ruby. It was so great to be there, and to be a part of it. Ruby had a major presence every day of the conference.
Monday, both tutorials—Dave Thomas’ intro to Ruby, and David Heinemeier Hansson’s intro to Rails—were in the large tutorial room, and were packed. At Tuesday evening’s extravaganza, David won the best hacker award, and Ruby got several nods in Damian Conway’s unbelievably entertaining talk. Wednesday morning during the keynote, Tim O’Reilly discussed Ruby’s small but growing share of the programming language book market, and speculated that Ruby might be “the Perl of Web 2.0.”
David led off an eventful Thursday with a keynote on “The Secrets of Rails.” All of Thursday’s Ruby talks were standing-room only, and for three of them people were turned away because there was no place for them. Why’s multimedia extravaganza was moved to a larger and more suitable room (thanks to Nat Torkington and the O’Reilly conference staff) and turned into the most memorable event of any conference I’ve ever seen.
Finally, Danny O’Brien’s Friday “To Evil” keynote topped it all off, hilariously citing Ruby as a notable exception to Gandhi’s famous quotation. Why? Because it went directly from “they ignore you” to “you win” in about three weeks.
Jokes aside, this week alone shows that Ruby has arrived.