This post originated from an RSS feed registered with Ruby Buzz
by David Heinemeier Hansson.
Original Post: Rails perspective from the guy at the bank
Feed Title: Loud Thinking
Feed URL: http://feeds.feedburner.com/LoudThinking
Feed Description: All about the full-stack, web-framework Rails for Ruby and on putting it to good effect with Basecamp
Michael Koziarski works for the canonical enterprise corporation: A bank. So the day job is all about Hibernate, Struts, Spring, and how to integrate that kind of infrastructure with legacy COBOL applications. Here's what he has to say about Ruby on Rails:
Rails is perhaps the most productive web development environment I’ve ever used. It’s simple, elegant and understandable. I’ve had some configuration files that are bigger than Basecamp (4kLoc)
If I were building an application for myself, or to start a web based business, I’d definitely choose Rails. In terms of time to market and maintenance costs I don’t think I could seriously consider using J2EE or PHP. Similarly, if I were doing contract development for small or medium clients, I’d strongly urge them to consider rails.
Beyond the fantastic endorsement (thanks!), Michael goes on to talk about why Rails probably isn't suitable for his work at the bank. He brings up issues about finding Ruby programmers as easily as in Java and about how DBAs won't let you get away with an easy and understandable schema. While I have no intentions of convincing Michael to push Ruby on Rails at the bank1, I'll try to give my observations anyway.
Within a week, the team of three PHP programmers took in test- and domain-driven development, the Model-View-Control separation, and got fairly proficient with Ruby on Rails. Before my stay, they hadn't done any Ruby or even Rails before. I was pretty impressed with their ability to grok it quickly and further convinced that good programmers can adapt to new environments much easier than most people expect.
So stop worrying too much about finding people with x years of experience in y and look for people who are adaptable and good programmers. They'll learn Ruby on Rails easily. It's likely going to take them longer getting up to speed on the specifics of your application than adapting to the environment.
The DBA distortion filter
I have no doubt that there are DBAs out there that know a great many things about what makes a database tick, but every time I discuss their role with other programmers I get the distinct impression that their primary role is as a distortion device.
As a recent example, Jim Weirich was telling at RubyConf about how he'd submit a database schema to DBA process and pray it wouldn't get mangled too badly. Usually it would. Non-sensical prefixes would be injected, additional columns that might be useful some day would get added, and the turn around time would probably be about a week.
This sounds like a similar to what Michael is talking about:
I don’t know many DBA’s who’d let you call primary key’s “id”, or let your name your tables simply, without some whacked ‘standard’.
I wonder if there are any DBAs out there that has yet jumped on the agile principles of Do The Simplest Thing Possible and You're Not Gonna Need It. It sounds like a lot of them are still caught up in Big Upfront Design.
So maybe you need to route around the damage if distortions is truly what you're getting back? So opt out of the DBA (if he functions are characterized above) instead of "perhaps the most productive web development environment".
In the end, it's all about delivering the maximum amount of value to the stake holders. Doing so is usually fairly correlated with productivity. But regardless, I'm really happy to see that there's a discussion going on.
1 My Jedi mind tricks needs at least a few more strokes of confidence before I'd tackle an uphill battle like that
Previous Topic
