How can I defend Ruby on Rails against customers' not technical opinion?

Question

My customer, a translations business owner, just told me that he has been reading about Ruby on Rails and told me that "there are more PHP guys around there" and "it seems the community prefers it". What would you, as software engineer and freelancer, say to the customer to achieve these goals:

• Sell
• Make him see that the technology is my expert decision and Rails is as good or better than PHP (+ whatever framework) for this particular project.

UPDATE: Thank you all for the suggestions! Tomorrow I've got another meeting with him, let's see how it goes, I will update again :)

UPDATE 2: Finally I told him to read this thread and the result has been fantastic: He gave me the project and we are going to start right now. Thank you all for the help, you have free beer in my charge if we see someday :)

BTW: I learned the lesson: be as transparent as possible, because if you believe in yourself and your work, there is no question compromising enough to beat you.

regards

Answer 1

I think you make a mistake in assuming that the choice of technology is a purely technical decision.

The customer seems to be concerned about the business implications of picking a particular technology. Given that, you need to present a case that addresses his business concerns at least as heavily as your technology opinions.

• Employers have to recruit from a particular geographic area and certain areas have particularly active communities around particular technology stacks. If you're starting a business in the Pacific Northwest of the US, for example, there would be a strong bias towards a Microsoft stack simply because Microsoft is very influential in the area so most of the developers you'd be looking to hire would have experience with that stack. Other geographical regions have very different profiles.
  Talk with your customer and understand why and how he formed his opinion. Perhaps he read that the local PHP community is particularly active or that the local college teaches a lot of PHP and no Ruby. Perhaps he's got a trusted developer that he can call in for the occasional emergency that is a PHP pro and a Ruby neophyte. Of course, it's also possible that he's using poor metrics like the number of job ads or resumes that mention various keywords.
• Employers have to be concerned with the long-term sustainability of technology stacks. Years ago, for example, lots of companies invested a great deal of time and effort building PowerBuilder apps (and other languages of that genre). PowerBuilder often made it very easy to build line of business apps and developers at the time were often quite enamored with it. Unfortunately, the PowerBuilder community more or less collapsed leaving companies in a situation where they had a lot of existing code in a language no one really wanted to use where they had difficulty getting competent developers to maintain the existing code and expensive, time-consuming projects to migrate those apps to other technology stacks. The relative technical merits of PowerBuilder were vs. Java or C++ or C# or whatever they migrated to at that point; it was a death spiral since developers didn't want to get stuck working in a language that companies wanted to migrate away from and companies saw the lack of developers as a sign they should redouble their migration efforts to ensure they had the capacity to do the development the business needed.
  Relatively niche languages like Ruby absolutely have the potential to create these sorts of legacy problems for companies who can't predict whether the language is going to fizzle out in a few years when people move on to the next fad or if it has real staying power. You can certainly mitigate this by pointing out that Ruby isn't dependent on one company or organization so no one can decide it is no longer a strategic product for the company. If your customer has been burned in the past by having applications developed in languages that became business headaches, you'll need to make a case that Ruby is more like Linux and other open source technologies that flourished without a company backing them than languages that have died out over the years.
• Employers want consistency in the environment so choosing a language for one project forces a choice for many others. Even if Ruby is technically ideal for the project you're pitching, you have to explain why it's appropriate for every other application this customer is going to need developed or explain what mix of technologies you believe are appropriate (i.e. Ruby for X, something else for Y). Dealing with heterogeneous technologies, however, inevitably translates into extra cost for the business.

Answer 2

For starters, you can direct you client here for a look at the ecosystem that exists around Rails. You can also point to the successful startups like LivingSocial, Shopify, 37signals, etc. that built their businesses with Ruby and Rails.

You can mention that massive enterprises like AT&T, SAP, and Symantec are using Rails, too (they were all heavily recruiting at RailsConf last year).

You can point out that a translations business has a lot to gain by using a language/framework that makes Unicode support and i18n relatively painless.

Ultimately, I think you need to sell the idea that being able to use Rails is a premium feature he gets by hiring you: "Of course all those other guys are using PHP. But you have the opportunity to have a modern stack powering your application."

At the end of the day, it also needs to be clear that what he's ultimately buying is your skill and expertise; if he was that knowledgeable on server-side web technologies, he wouldn't need you. Language and framework are implementation decisions, not requirements.

P.S. Don't mention Twitter. We're still trying to undo the bad PR Rails took from that.

Answer 3

He's talking about people, you're talking about a language and framework. He is not going to hear any reasons that are purely technical, so you should focus on what people are doing with the language. You can talk about people-power under Rails, how it's easier for one person to do more than a PHP person, faster (if this is what you believe). You can ask whether the prevalence of Honda drivers means it's a better car than a Rolls Royce, which is rarely seen. You can talk about what the community is actually comprised of, whether there are too many cooks in the module soup (gems vs. modules, etc.), whether everybody has NIH syndrome, and so on.

Regardless, it needs to be in terms of people because he wants to know that he can replace you. Help him to know this, because he (probably) won't want to switch away anyway. Your "expert decision" has absolutely no bearing when he gives much less care to what a given person knows. He just wants there to be "more people" who know the same thing.

At the end of the day, there's no shame in calling his bluff. "Fine, go with PHP. Good luck!"

Answer 4

I'd explain that it's basically a "Coke" vs. "Pepsi" choice. Both are widely accepted, both have people that will fight and die for each, and they're both perfectly adequate. Point out the reasons you prefer RoR.

Answer 5

Point out that the PHP crowd has more members because its the lowest barrier to entry and has been around longer. Make sure to point out that smaller communities have higher percentages of programmers worth hiring, PHP may have 10,000 good programers compared to 5,000 rails programmers, but the PHP programmers are hidden in a block of 100,000 compared to 20,000 for rails programers. (These numbers are made up, but it gets the point across.) Then you need to explain that the community really doesn't have a preference between PHP and Rails.

You can't use technical reasons on a non technical person, you can't explain why the iPhone is inferior to other smartphones to someone who only knows about what phones look like. You need reasons they understand.

Answer 6

Your customer hired you, so presumably he trusts your expertise. Explain that different professionals may prefer different tools, and your preferred tool happens to be RoR. Point out the presence of the community and the community acceptance that exists for RoR and successful companies like 37signals using it, to remove his concern that you are recommending some arcane technology that nobody but you knows about. Point out that you will be more productive using the tools you prefer (thus lowering his costs and improving his changes on success) and that if you or him ever need to find more RoR experts it won't be hard to do. If he's more technical you may point out how RoR can be successful in the tasks he needs compared no less than his preferred solution.

Avoid repeating FUD and generally disparaging PHP - if you're not an expert in PHP, there's a high probability you'll say something that is not accurate, wrong or highly controversial, and if your customer learns you were wrong on that it may hurt your credibility with him in other aspects.

Answer 7

Your boss has a point. PHP is much more popular than RoR accoding to several sites that endeavor to keep track of such things. For example, see http://lang-index.sourceforge.net and http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html>. I think it would be foolish to ignore the facts.

I suggest you acknowledge he has a point and then remind him that RoR is has a strong following too. It wouldn't hurt to have a few links to popular sites built with RoR that you can show him.

After all, he is really looking for your assurance that he is making the right business decision and wants the evidence to back it up. As the old saying goes "No one ever had arrows shot at them for recommending Microsoft." Same goes for PHP in web development. Give him solid facts and eschew opinions. You'll do fine.

Answer 8

Translate your beliefs into quantifiable economic terms (if possible/valid). The fact that his business is translation specific suggests that RoR (or any language with native multilingual support) is technically superior to PHP - but this has to be offset against the costs of developers and server provisioning associated with those respective platforms. Their business is likely to last longer than your relationship, they will want reassurance that they are laying the right foundations.

IME, admitting the cons (as well as the pros) of your strategy is more convincing than any amount of evangelism - it suggests that you are more interested in solving their problem than using your favourite hammer.

Answer 9

Your customer could have a valid point. Supply and demand affects prices. If the supply of developers with a particular skill in the customers geographic area is low, the price for maintaining software requiring that rarer skill set could increase more over time than if the software were developed using a more popular language for which there was a significantly larger local pool of skilled developers. So the issue could also be one of long term cost risk management.

Answer 10

When I have a client who is wanting to use a particular tool because it's "industry standard," has a "consensus," or is "what everybody's using," I point out to them that all those terms are code for "industry average." That is, what most of the other people in the area are doing. The "average" business fails. Pick your tools based on the job requirements, not on what everyone else is doing. There being fewer RoR programmers doesn't matter if the system doesn't need as much tinkering with when it's done.

Answer 11

Surely this is a business decision for both of you.

For you the questions are:

• How much will it cost me to implement my customers requirements using Ruby on Rails?
• How much will it cost me to implement them in PHP?
• What value do I place on using my preferred environment?

For your customer, the question is

• How much are the perceived benefits of PHP over Ruby on Rails worth to me?

If you provide your customer with a quotation with a Price for implementation using Ruby on Rails and a separate Price for implmentation using PHP, both based on the answers to your own questions, then your customer can make their own judgement call as to whether the extra cost now is worth possible future savings.

This is no different to them making a decision as to whether they should give the contract to you, or to another developer who would implement it using PHP as requested.

Answer 12

The best real world analogy I can come up with is "Would buy a Ford rather than a BMW just because BMW's market share is smaller?".

Answer 13

Ultimately, PHP programmers are half the cost of Rails programmers, and what you if you find a better job tomorrow? Your boss would be totally screwed and scrambling to find a Rails developer, and that takes time and money since Rails developers are in short supply.

The only reason your boss would agree to it is if it feels like it would make YOU happier, and that by allowing to make the decisions that you want you would be happier working for him, and thus be more productive.