Being Conventional

One of the biggest selling points about Ruby on Rails is that it favors "convention over configuration." By following certain well-documented conventions in development, you can eliminate the need for all but the most fundamental configuration in your application. This appeals to developers who tire of the endless, often repetitive configuration tasks required by other languages and frameworks. Not surprisingly, this is also one of the most controversial features of Rails, especially among people who are used to doing things differently. It's possible to use Rails without sticking to its conventions; but, it's neither easy, nor fun. For those developers who have mastered the endless, repetitive configuration style, Rails' approach is limiting at best, and completely incompatible at worst. This reflects one of the key struggles in modern society: how to simultaneously leverage and break free of convention. Everyone's heard admonishments against re-inventing the wheel; at the same time, we are encouraged to transcend the status quo. If you stick entirely to convention, you don't evolve; if you consistently ignore convention, you may find yourself extinct. Balance can be hard to find. At Viget Labs, we're embracing Ruby on Rails. In doing so, we're having to find our own balance. Collectively, we have decades of development experience, but most of it is not with Rails given its short history. Much of our previous work was done in PHP, a language without much in the way of convention compared to Rails. Like many other organizations that work in PHP, Java, or other platforms, Viget created its own conventions -- an application framework, numerous libraries, and other specific solutions. Viget Labs is growing. We're hiring all types of talented people, including developers. We need to expand our staff to maintain our growth; more importantly, we need people who are ready to go now. We've got work to do, and we want our people to get a smooth, quick start. We don't want them bogged down having to learn proprietary methods that they'll have never seen before. This is where Ruby on Rails is a big win. As we continue to let go of our old ideas and do things "the Rails way," we make it much easier for a new developer to join our team and jump right onto a project. There's no need for a new developer to spend days or weeks learning our proprietary framework. Our new developers will already know Rails, so they'll just need to be oriented to our environment and to the few things we do differently (because there will always be things that are unique about Viget). This is, in fact, exactly how things worked when I joined Viget earlier this year. After about a day and a half of orientation, paperwork, and other overhead, I jumped into my first project. When that project launched, I moved smoothly to my next project, and so on. I didn't have to spend a week or two reading up on Viget's proprietary libraries or frameworks; just a few pair sessions with my fellow developers were enough to give me the lay of the land. My prior knowledge of Rails got me going quickly. At Viget Labs, we don't want you to think of us as "conventional." Conventional web shops are a dime a dozen: we're better than that. But that doesn't mean we can't use convention to our advantage. By choosing to work within the conventions of Ruby on Rails instead of going our own way, we're eliminating barriers to growth and quality. And that means more satisfaction all around, from our team members to our customers.
Mark Cornick

,
Posted in Article Category: #Code
on