At The Frontier Group in 2006, we were faced with a choice. To continue building our customers web applications in PHP, or to make a shift to an up-and-coming language and framework: Ruby on Rails.
We were a small team of 5 and every new project could be evaluated on its own merits. Our CIO had been following and researching Rails for a few months and this looked like an opportunity worth exploring.
In 2007 we began developing solely in Rails and haven’t looked back. Our ability to deliver small prototypes and large enterprise applications has flourished and the business grew 400% in 18 months.
But after developing solely in PHP for 4 years, just what were those reasons at a business level to make a shift to a completely new (and immature) language, effectively changing our whole business dynamic.
For years we had leveraged open source technologies, languages and code. The Rails community was opinionated, it was growing and it matched our value set. We saw a way that we could continue to “take” but also begin to “give back”.
Since switching to Rails we have made real friendships with hundreds of other developers, spoken and met with many of our programming “idols”, helped other developers with their projects, released patches, bug fixes and new plugins back into the open source Rails community.
There’s a constant buzz in the Rails community and this was one of the biggest factors in aligning ourselves with a particular language. It wasn’t all about the bottom line.
We’re an Agile company and our development processes just mesh with Rails and the Rails way so much better. Switching to Rails meant we could run projects the way we wanted (and needed) to. Moving away from the traditional waterfall model was a snap.
Rails makes it easy to get an application prototype up and running, showing a real business value for the project in the early stages. Perfect for startups, but this was also key for finding and keeping larger enterprise clients. Who can argue with the choice of framework, when your application is useable in the opening months of development?
Productivity vs Cost
Here’s where the bottom line does come into it. At the end of the day, most clients have a limited budget. Or they have someone overseeing development funds. If you can’t deliver as good or better than the next company, you’re not going to win work. With PHP we were a dime a dozen. Using a niche framework, we had a selling point. A talking point.
There were plenty of articles on the web about productivity and project timelines in Rails. Lower development costs, shorter delivery timeframes. All the buzzwords. Rails was still new and we had to prove it was true, but seeing it in action meant we were sure we could be more effective with this framework.
PHP programmers are everywhere. Hiring PHP developers is a no brainer exercise. Rails developers on the whole, were a different breed. Incredibly passionate & opinionated. People who loved development were choosing this framework. We saw potential to build our business around people who loved what they do. In the past few years that talent pool has grown and so has the community aspect around Rails.
Some say, The Rails community can be likened to an exclusive fan club. Ken Loh, web director at Oakley said:
Rails developers are a passionate bunch. It’s almost like a religion to them. Gartner says there are a million Ruby programmers today, but analyst Mark Driver reckons that by 2013 there will be four million. A June survey by software development research company Evans Data found that Ruby use in North America alone has jumped 40% in the past year, with 14% of developers now using it at least part of the time. In emerging economies, it’s even bigger.
The talent pool is growing, and its growing out of enthusiasm and interest, not out of necessity. That really helps when it comes to the hiring process.
Those four areas were the key business decisions to move the company ahead with Rails development. It’s been a great ride!
Other Sites Based On Rails