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.