Comment puis-je défendre Ruby on Rails contre l'avis non technique des clients?

Mon client, propriétaire d'une entreprise de traduction, vient de me dire qu'il avait lu sur Ruby on Rails et m'a dit qu '" il y a plus de gars PHP par là " et " il semble que la communauté le préfère ". Que diriez-vous, en tant qu'ingénieur logiciel et pigiste, au client pour atteindre ces objectifs:

• Vendre
• Faites-lui voir que la technologie est ma décision d'expert et que Rails est aussi bon ou meilleur que PHP (+ quel que soit le framework) pour ce projet particulier.

MISE À JOUR: Merci à tous pour les suggestions! Demain, j'ai une autre rencontre avec lui, voyons comment ça se passe, je mettrai à jour :)

MISE À JOUR 2: Enfin je lui ai dit de lire ce fil et le résultat a été fantastique: il m'a donné le projet et nous allons commencer tout de suite. Merci à tous pour l'aide, vous avez de la bière gratuite à ma charge si nous voyons un jour :)

BTW: J'ai appris la leçon: soyez aussi transparent que possible, car si vous croyez en vous-même et en votre travail, il ne fait aucun doute de compromettre suffisamment pour vous battre.

Cordialement

Je pense que vous faites une erreur en supposant que le choix de la technologie est une décision purement technique.

Le client semble être préoccupé par les implications commerciales du choix d'une technologie particulière. Compte tenu de cela, vous devez présenter un cas qui répond à ses préoccupations commerciales au moins autant que vos opinions technologiques.

• Les employeurs doivent recruter dans une zone géographique particulière et certaines zones ont des communautés particulièrement actives autour de piles technologiques particulières. Si vous démarrez une entreprise dans le Pacifique Nord-Ouest des États-Unis, par exemple, il y aurait un fort parti pris vers une pile Microsoft simplement parce que Microsoft est très influent dans le domaine, donc la plupart des développeurs que vous cherchez à embaucher le feraient. avoir de l'expérience avec cette pile. D'autres régions géographiques ont des profils très différents.
  Discutez avec votre client et comprenez pourquoi et comment il s'est fait son opinion. Peut-être qu'il a lu que la communauté PHP locale est particulièrement active ou que le collège local enseigne beaucoup de PHP et pas de Ruby. Peut-être qu'il a un développeur de confiance qu'il peut appeler pour l'urgence occasionnelle qui est un pro PHP et un néophyte Ruby. Bien sûr, il est également possible qu'il utilise des statistiques médiocres comme le nombre d'annonces d'emploi ou de curriculum vitae mentionnant divers mots clés.
• Les employeurs doivent se préoccuper de la durabilité à long terme des piles technologiques. Il y a des années, par exemple, de nombreuses entreprises ont investi beaucoup de temps et d'efforts pour créer des applications PowerBuilder (et d'autres langues de ce genre). PowerBuilder a souvent facilité la création d'applications métier et les développeurs à l'époque en étaient souvent très séduits. Malheureusement, la communauté PowerBuilder s'est plus ou moins effondrée, laissant les entreprises dans une situation où elles avaient beaucoup de code existant dans une langue que personne ne voulait vraiment utiliser là où elles avaient du mal à trouver des développeurs compétents pour maintenir le code existant et des projets coûteux et chronophages. pour migrer ces applications vers d'autres piles technologiques. Les mérites techniques relatifs de PowerBuilder étaient par rapport à Java ou C ++ ou C # ou quoi qu'ils aient migré à ce moment-là;
  Des langues relativement niches comme Ruby ont absolument le potentiel de créer ce type de problèmes hérités pour les entreprises qui ne peuvent pas prédire si la langue va se dissiper dans quelques années lorsque les gens passeront à la mode suivante ou si elle a une réelle capacité de survie . Vous pouvez certainement atténuer cela en soulignant que Ruby ne dépend pas d'une seule entreprise ou organisation, de sorte que personne ne peut décider qu'il ne s'agit plus d'un produit stratégique pour l'entreprise. Si votre client a été brûlé dans le passé en faisant développer des applications dans des langues qui sont devenues des maux de tête, vous devrez démontrer que Ruby ressemble plus à Linux et à d'autres technologies open source qui ont prospéré sans qu'une entreprise les soutienne que des langues qui ont disparu au fil des ans.
• Les employeurs veulent de la cohérence dans l'environnement, donc choisir une langue pour un projet oblige un choix pour beaucoup d'autres. Même si Ruby est techniquement idéal pour le projet que vous présentez, vous devez expliquer pourquoi il convient à toutes les autres applications que ce client aura besoin de développer ou expliquer la combinaison de technologies que vous jugez appropriées (par exemple Ruby pour X, autre chose pour Y). Cependant, la gestion de technologies hétérogènes se traduit inévitablement par des coûts supplémentaires pour l'entreprise.

Pour commencer, vous pouvez diriger votre client ici pour un aperçu de l'écosystème qui existe autour de Rails. Vous pouvez également désigner les startups à succès comme LivingSocial, Shopify, 37signals, etc. qui ont bâti leurs entreprises avec Ruby et Rails.

Vous pouvez mentionner que des entreprises massives comme AT&T, SAP et Symantec utilisent également Rails (elles recrutaient toutes massivement chez RailsConf l'année dernière).

Vous pouvez souligner qu'une entreprise de traduction a beaucoup à gagner en utilisant un langage / framework qui rend la prise en charge Unicode et i18n relativement indolores.

En fin de compte, je pense que vous devez vendre l'idée que pouvoir utiliser Rails est une fonctionnalité premium qu'il obtient en vous embauchant: "Bien sûr, tous ces autres gars utilisent PHP. Mais vous avez la possibilité d'avoir une pile moderne alimentant votre application . "

À la fin de la journée, il doit également être clair que ce qu'il achète en fin de compte, c'est votre compétence et votre expertise; s'il connaissait bien les technologies Web côté serveur, il n'aurait pas besoin de vous. Le langage et le cadre sont des décisions de mise en œuvre, pas des exigences.

PS Ne mentionnez pas Twitter. Nous essayons toujours de défaire les mauvaises relations publiques que Rails en a tirées.

J'expliquerais que c'est fondamentalement un choix "Coke" contre "Pepsi". Les deux sont largement acceptés, les deux ont des gens qui se battront et mourront pour chacun, et ils sont tous les deux parfaitement adéquats. Indiquez les raisons pour lesquelles vous préférez RoR.

Il parle de gens, vous parlez d'un langage et d'un cadre. Il n'entendra aucune raison purement technique, vous devez donc vous concentrer sur ce que les gens font avec la langue . Vous pouvez parler de la puissance des personnes sous Rails, comment il est plus facile pour une personne de faire plus qu'une personne PHP, plus rapidement (si c'est ce que vous croyez). Vous pouvez vous demander si la prévalence des conducteurs Honda signifie que c'est une meilleure voiture qu'une Rolls Royce, ce qui est rarement vu. Vous pouvez parler de la composition réelle de la communauté, s'il y a trop de cuisiniers dans la soupe du module (gemmes vs modules, etc.), si tout le monde est atteint du syndrome NIH, etc.

Quoi qu'il en soit, cela doit être en termes de personnes, car il veut savoir qu'il peut vous remplacer. Aidez-le à le savoir, car il ne voudra (probablement) pas partir de toute façon. Votre «décision d'expert» n'a absolument aucune incidence lorsqu'il accorde beaucoup moins d'attention à ce qu'une personne donnée sait. Il veut juste qu'il y ait "plus de gens" qui connaissent la même chose.

À la fin de la journée, il n'y a aucune honte à appeler son bluff. "Très bien, allez avec PHP. Bonne chance!"

Faites remarquer que la foule PHP compte plus de membres, car c'est la plus faible barrière à l'entrée et existe depuis plus longtemps. Assurez-vous de souligner que les petites communautés ont des pourcentages plus élevés de programmeurs à embaucher, PHP peut avoir 10000 bons programmeurs par rapport à 5000 programmeurs de rails, mais les programmeurs PHP sont cachés dans un bloc de 100000 par rapport à 20000 pour les programmeurs de rails. (Ces chiffres sont composés, mais cela fait passer le message.) Ensuite, vous devez expliquer que la communauté n'a vraiment pas de préférence entre PHP et Rails.

Vous ne pouvez pas utiliser des raisons techniques sur une personne non technique, vous ne pouvez pas expliquer pourquoi l'iPhone est inférieur aux autres smartphones à quelqu'un qui ne connaît que l'apparence des téléphones. Vous avez besoin de raisons pour lesquelles ils comprennent.

Votre client vous a embauché, alors il fait probablement confiance à votre expertise. Expliquez que différents professionnels peuvent préférer différents outils, et que votre outil préféré se trouve être RoR. Soulignez la présence de la communauté et l'acceptation de la communauté qui existe pour le RoR et les entreprises prospères comme 37signals qui l'utilisent, pour dissiper son inquiétude que vous recommandiez une technologie mystérieuse que personne mais vous ne connaissez. Faites remarquer que vous serez plus productif en utilisant les outils que vous préférez (réduisant ainsi ses coûts et améliorant ses changements en cas de succès) et que si vous ou lui avez besoin de trouver plus d'experts RoR, ce ne sera pas difficile à faire. S'il est plus technique, vous pouvez souligner comment RoR peut réussir dans les tâches dont il a besoin par rapport à sa solution préférée.

Évitez de répéter FUD et généralement dénigrer PHP - si vous n'êtes pas un expert en PHP, il y a de fortes chances que vous disiez quelque chose qui n'est pas précis, erroné ou très controversé, et si votre client apprend que vous aviez tort, cela pourrait blesser votre crédibilité auprès de lui sous d'autres aspects.

Votre patron a raison. PHP est beaucoup plus populaire que RoR accoding à plusieurs sites qui s'efforcent de garder une trace de ces choses. Par exemple, voir http://lang-index.sourceforge.net et http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html >. Je pense qu'il serait stupide d'ignorer les faits.

Je vous suggère de reconnaître qu'il a un point et de lui rappeler ensuite que RoR est également très suivi. Cela ne ferait pas de mal d'avoir quelques liens vers des sites populaires construits avec RoR que vous pouvez lui montrer.

Après tout, il recherche vraiment votre assurance qu'il prend la bonne décision commerciale et veut que les preuves la corroborent. Comme le dit le vieil adage "Personne n'a jamais tiré sur des flèches pour avoir recommandé Microsoft." Il en va de même pour PHP dans le développement Web. Donnez-lui des faits solides et évitez les opinions. Vous ferez bien.

Traduisez vos croyances en termes économiques quantifiables (si possible / valides). Le fait que son entreprise soit spécifique à la traduction suggère que RoR (ou tout autre langue avec un support multilingue natif) est techniquement supérieur à PHP - mais cela doit être compensé par les coûts des développeurs et de l'approvisionnement des serveurs associés à ces plateformes respectives. Leur entreprise est susceptible de durer plus longtemps que votre relation, ils voudront avoir l'assurance qu'ils posent les bonnes bases.

IME, admettre les inconvénients (ainsi que les avantages) de votre stratégie est plus convaincant que n'importe quelle quantité d'évangélisation - cela suggère que vous êtes plus intéressé à résoudre leur problème qu'à utiliser votre marteau préféré.

Votre client pourrait avoir un point valide. L'offre et la demande affectent les prix. Si l'offre de développeurs ayant une compétence particulière dans la zone géographique des clients est faible, le prix de la maintenance d'un logiciel nécessitant cet ensemble de compétences plus rare pourrait augmenter plus dans le temps que si le logiciel était développé en utilisant un langage plus populaire pour lequel il y avait un plus grand pool local de développeurs qualifiés. Le problème pourrait donc aussi être celui de la gestion des risques de coûts à long terme.

Quand j'ai un client qui veut utiliser un outil particulier parce qu'il est «standard de l'industrie», a un «consensus» ou est «ce que tout le monde utilise», je leur fais remarquer que tous ces termes sont du code pour «moyenne de l'industrie». " C'est ce que font la plupart des autres habitants de la région. L'entreprise "moyenne" échoue. Choisissez vos outils en fonction des exigences de l'emploi et non de ce que font les autres. Le fait qu'il y ait moins de programmeurs RoR n'a pas d'importance si le système n'a pas besoin d'autant de bricolage lorsqu'il est terminé.

C'est certainement une décision commerciale pour vous deux .

Pour vous, les questions sont:

• Combien cela me coûtera-t-il pour implémenter les exigences de mes clients à l'aide de Ruby on Rails?
• Combien cela me coûtera-t-il de les implémenter en PHP?
• Quelle valeur accorder à l'utilisation de mon environnement préféré?

Pour votre client, la question est

• Combien me valent les avantages perçus de PHP par rapport à Ruby on Rails?

Si vous fournissez à votre client un devis avec un prix pour l'implémentation à l'aide de Ruby on Rails et un prix distinct pour l'implémentation à l'aide de PHP , tous deux basés sur les réponses à vos propres questions, alors votre client peut faire ses propres jugement quant à savoir si le supplément le coût vaut maintenant des économies futures possibles.

Ce n'est pas différent pour eux de décider s'ils devraient vous donner le contrat, ou à un autre développeur qui le mettrait en œuvre en utilisant PHP comme demandé.

La meilleure analogie du monde réel que je peux trouver est "achèterait une Ford plutôt qu'une BMW juste parce que la part de marché de BMW est plus petite?".

En fin de compte, les programmeurs PHP coûtent la moitié du coût des programmeurs Rails, et qu'allez-vous faire si vous trouvez un meilleur emploi demain? Votre patron serait totalement foutu et se bousculerait pour trouver un développeur Rails, et cela prend du temps et de l'argent car les développeurs Rails sont en nombre insuffisant.

La seule raison pour laquelle votre patron serait d'accord, c'est s'il a l'impression que cela VOUS rendrait plus heureux, et qu'en permettant de prendre les décisions que vous voulez, vous seriez plus heureux de travailler pour lui, et donc plus productif.