November 07, 3:47
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.
The perceived problems of finding Ruby talent
The hiring approach seems to commit Hiring Mistake #1: Hiring Tools, Not People, as Johanna calls it. After the week in Vancouver, I feel even more strongly that this is true.
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
Challenge by gabriele on November 07, 11:34
I guess some of the principles of agile modeling may apply..
think of the "Travel Light principle" ( you create just enough models to get by), it matches YAGNI wquite good.
Challenge by Phil Wilson on November 07, 16:56
Hmmmm...DBA as an impediment. Being a DBA myself I fully understand how this can happen. DBAs, like many technical positions within the industry have often been placed as bottlenecks to ensure that there was a traffic cop to police "corporate standards".
In many cases, corporate standards are required, but they need not be ridiculous. I agree that it isnt the DBA's job to "mangle" the schema a developer provides. Alternatively, the developer often shortcuts the analysis phase and does only what is required to solve the task at hand. I insist on being a part of the design process up front so that I can offer advice before it gets to be a confrontation between developer and dba. I can offer data modelling advice and coach on standards that help all developers, not just the one submitting the current piece of work.
All this being said, I have no problem with the current data model naming conventions used in Rails. As a DBA and a developer I search for the solution that accomodates all, but tries to provides maximum efficiency as well.
Quite often, the data model is what holds back many software products. If it were properly engineered at the beginning and well thought out (possibly through the help of a DBA) adding features wouldnt be such a chore. Many open source products suffer from this initially until those involved realize they cannot just throw together a few tables to accomplish their goal.
I know a great many DBAs that think they are the only ones holding the key to the well-being of a project. I also know many great DBAs that came from the developer ranks and understand it takes teamwork and knowing the value of each persons strengths to make a project succeed. The DBAs with the development experience are generaly more open to working outside the vacuum of the database.
Challenge by evan on November 07, 20:06
I've used rails to develop a small application which was driven off of a legacy database. I found that it was relativily easy to override the field and table name assumptions. For me, the flexiblity to do that, was critical in my considering the adoption of Rails.
Challenge by Joe on November 08, 15:46
Working at a bank, I can tell you that the biggest barrier to adoption is probably going to be audit concerns. Banks are audited. A lot. Usually, the IT auditor isn't someone who knows anything about IT, but is instead someone who has been trained how to conduct an IT audit. So what you try to do is put a big book of documentation and procedures in front of them that says, "Here are the answers to all the questions you're going to ask."
If you're running solutions that are well known to the auditors (say, Oracle ERP, for example), they are usually very comfortable, do a few cursory checks of key elements, and move on. If you throw something they've never heard of at them, they spend A LOT more time trying to examine it, and given that they're not always IT folk, this is usually an akward and fruitless endeavour for everyone involved.
Many times, banks aren't able to adopt new technology until other industries are picking it up, for exactly this reason.
Challenge by Michael Koziarski on November 08, 20:57
Hey David,
glad you liked the review. I'm hoping to get more comfortable with Rails in the next few months, so I can start using it for my own projects.
If I come accross anything I can help with, I will.
Challenge by Chris Rimmer on November 08, 20:58
Hibernate, Struts and Spring? That sounds like a fairly agile toolset. It could be a hell of a lot worse - the "standard" way to do J2EE development involves EJBs. Naaaaasty...
Challenge by poker rules on June 21, 1:16
In your free time, visit the sites about poker rules poker rules http://poker-rules.zindagi.us/ ...
Challenge by free poker on June 21, 9:15
You are invited to check out the pages on free poker free poker http://www.poker-adventure.com/free-poker.html - Tons of interesdting stuff!!!
Challenge by internet casino on June 22, 8:17
You are invited to check out some helpful info in the field of internet casino internet casino http://www.scottishtutors.com/internet-casino.html ...
