FiveRuns Blog

We’re excited to launch a new interview series on the FiveRuns blog – Rails TakeFive – to provide insight and commentary from notable members of the Ruby and Rails community, with the goal of facilitating an ongoing conversation around all things RoR. We welcome your suggestions for interviewees and questions. Look for a new post every Friday!

We’re proud to have Chad Fowler, noted software developer, Ruby Central co-founder, and author kick off the series.

FiveRuns: Welcome, Chad. And thanks again for helping with the inaugural TakeFive post. We’ve seen job listings that amusingly seek “a Ruby on Rails expert with 5 or more years of experience.” What does the job market look like these days for Ruby or Rails developers?

Chad Fowler: Although Rails has been picking up steam, there are still, compared to other technologies, very few jobs available. As soon as you get into the large-scale, mainstream job ecosystem, the skill of delivering applications in that environment becomes a commodity, so you end up competing with a larger pool of potential employees. Because of supply and demand balancing, the prices level out and you end up competing on price more than your skill as a developer. The good news about being a Rails developer now is – and I think this is good for both the employees and employers – that the conversation and negotiation you have when trying to get a Rails or Ruby job falls around how good you are and how much you can deliver as opposed to how much (or little) you cost.

As an indicator, not many offshore software development companies are doing Rails development. So you are often competing with leading edge early adopters, and the job market here – you are most likely to be placed in companies that are also leading-edge, early adopters, so it is a very healthy, vibrant, tough market albeit a small one.

FiveRuns: People always talk about “convention over configuration” as a paradigm that is central to why Rails works as well as it does. Can you say a little more for the newbies out there about why this so important?

Chad: Convention over configuration is a mantra made popular by Rails, but it should be something that everyone applies in all their software development efforts. Basically the idea is that, instead of making software ultra-configurable so you bend it to do anything you want it to do, Rails and like-minded software take low value decisions out of the process for you so you don’t have to spend time trying to figure out uninteresting things like how to organize source code layout, or how automated tasks should be run.

This all goes back to rebellion against the typical enterprise software mindset, which actually stems from negotiations with software vendors. When you are negotiating in a large company with a software vendor, they are charging a lot of money, and you typically ask them all these ‘what if’ questions trying to poke holes in their product. You are basically trying to make them tailor the product to your needs specifically. I know this from having worked at big companies and having been the person who does the negotiations themselves. In the end, you’ve poked so many holes and the product ends up being so configurable that there ends up not being one golden path to use the product. Therefore at a certain level, enough choice in terms of configuration makes the product implementation as bad as just programming your own code to start.

From a framework perspective, what Rails gives you is, as David Heinemeier Hansson calls it, liberation through constraints. You get to focus on the things that are important, building your application, and all of the low-value decisions are made for you.

FiveRuns: When is Ruby on Rails an appropriate choice for application development in the enterprise?

Chad: The obvious answer that everyone can regurgitate from the Web, is that if you’re doing a somewhat small, greenfield development, Ruby on Rails is a great choice. There are additional constraints, such as if your organization is the sort that can accept technology change and deal with heterogeneous environments and rapidly re-skilling developers (no formal training, certification) – basically if you’re more agile from a technology adoption standpoint – Rails might be appropriate.

It’s not as good when it comes to integrating with other technologies, as something like J2EE. This is based on relative age of Rails, specifically its age in terms of being used in the enterprise. So, for example if you want to connect to an IBM mainframe and and execute a legacy COBOL program in Java, there is probably a commercial library you can buy or an open source library you can download to do that. In Rails, that is not always the case but the reason is, in a lot of these different integration scenarios, no one has needed to do that yet with Rails. It’s not an inherent limitation. Just a maturity issue.

There will be people going forward that push Rails into situations that you may think of as not the best for Rails yet, but in doing this, they will make Rails more appropriate in a wider range of environments and applications.

FiveRuns: John K. Waters recently summed up a panel from QCon San Francisco in which he asked “So why is this free, open, easy-to-use, passionately advocated Web-app framework having such a hard time gaining serious traction in the enterprise?” What do you think?

Chad: My opinion is that the question itself is wrong. We don’t have any proof that Rails is having serious issues gaining traction in the enterprise. It may be that James the reporter expects because it is free and passionately advocated and that we all think it’s so great, that everyone else will get it and Rails will just get immediately adopted.

The truth is that it is being adopted in the enterprise. What measures success or trouble in this adoption process? My perspective is that Rails is being adopted at just the right rate, settling in small places and growing from there. There are more and more huge companies starting to adopt Rails, particularly for internal processes, or at least evaluating by sending people to training. My impression is that Rails is not actually having any more or less trouble than previous technologies, particularly open source technologies, have had with gaining adoption.

David Heinemeier Hansson’s infamous rhetoric which made the enterprise software world angry has, in a way, had the healthy effect of reigning in potentially destructively rapid growth and spread of Rails. Rapid adoption isn’t always necessarily a good thing.

FiveRuns: You’ve written before about being part of a “Big Rewrite.” What advice would you give to anyone about to take on such a project?

Chad: I have spent most of my career doing these big rewrites, and have seen many fail and a few succeed. The biggest piece of advice I have to give is never, ever do a Big Rewrite. That doesn’t mean you can’t rewrite your software but it means that huge, monolithic change is never easy and seldom good, at least in a business or a technology scenario. Even if you have a big rewrite in front of you, you need to think of it as many small rewrites. To do that, start by doing the necessary refactoring of the current system and current process such that you can turn the job into many small rewrites. That means investing time upfront on integration strategies, potentially refactoring the data model in your current software system; making it so you can break the system into small chunks. If you do these steps so you could do a rewrite, you may determine that your old technology was good enough, and what you were lacking was the discipline and rigor around processes and automation. You put those in place in the process of gearing up for a big rewrite and see that you don’t need to rewrite the software after all.

In summary, invest the time upfront so you can turn a big rewrite into many small rewrites.

Chad Fowler has been a software developer and manager for some of the world’s largest corporations. Until recently, Chad lived and worked in India, setting up and leading an offshore software development center. He is also co-founder of Ruby Central, Inc., a non-profit corporation responsible for the annual International Ruby and Rails Conferences, a leading contributor in the Ruby community and a contributor and editor for numerous books. Chad’s most recent book is Rails Recipes, published by the Pragmatic Programmers.

UPDATE: the quote attribution in question #4 has been changed from James Cox, who chaired the panel entitled “When Is Rails an Appropriate Choice?”, to John K. Waters, who wrote a summary of the panel discussion.