Effectivement c’est une approche, mais le risque est bien de prendre la mauvaise décision car des variables de l’équation sont mal quantifiées. Or on sait bien que les développeurs sont de très mauvais évaluateurs du temps nécessaire (trop optimistes ou pessimistes mais jamais réalistes).

Par ailleurs, je ne pense pas qu’on puisse déduire le seuil de rentabilité comme ça, car les choix techno ont des impacts directs (temps de dev pour une fonctionnalité donnée, …) mais aussi des impacts indirects, y compris comportementaux. Par exemple si une techno est fun, elle donnera plus envie à ses développeurs d’avancer, alors que si elle est casse pieds à utiliser, on va trainer les pieds et tout ça indépendamment du facteur de productivité des technos en question.

En résumé, je crois pas au choix basé uniquement sur des critères rationnels. Il ne faut pas oublier qu’au final ce sont des humains qui utilisent ça, qui en plus sont dans ce métier par passion, … donc avec des comportements et des attentes qui vont souvent au delà du rationnel.

by the way:
le seul framework zero bug? papier crayon boulier,et pigeon pou s’envoyer des messages !!!

Quel est le gain apporté par Ruby (en terme d’efficacité)?
Quel est le cout de formation des équipes en places?
Quel est le temps d’adaptation d’un développeur ?
Quel est le cout journalier d’un développeur?

Et tu tu calcul le seuil de rentabilité: combien de jours de devpt il me faut pour rentabiliser une migration vers Ruby.

factuel

La disponibilité des compétences sur le marché, donc.

Maintenant, quel que soit votre choix, je vous souhaite toute la réussite possible.

On ne renoncera pas à ce qu’on a déjà fait avec PHP/Symfony, ni aux compétences qu’on a sur ces sujets. On ne renoncera pas non plus au pendant Ruby/Rails.

On n’a pas vraiment besoin de petits projets pour évaluer la pertinence de Rails. Entre autres projets livrés, j’ai mené l’équipe technique de http://neomarco.com qui est complètement développé en Rails, et je travaille sur le back-office de notre second site en Rails.

Pour les comparaisons entre les 2 produits, on le fait implicitement tous les jours en voyant comment les choses sont faites dans l’un par rapport à l’autre, …

À part la “zone d’anxiété” (qui correspond à la période où il faut se lancer d’une de la nouveauté, dont ne mesure pas immédiatement les bénéfices, toute la lecture nécessaire, …) je ne vois vraiment pas quels sont les oppositions réelles.

Et puisque tu parles de Python/Django, je les place dans le même panier que Ruby/Rails, mais pas du tout PHP/Symfony.
Je n’ai jamais vraiment codé en Python, mais j’ai le sentiment que c’est un langage de la même trempe que Ruby. Ils se démarquent tous les 2 fortement de langages type PHP. Django dispose d’atouts forts et de poins faibles par rapport à Rails.

Mais je n’ai pas du tout senti ce plaisir à lire du Python comme je l’ai senti immédiatement avec Ruby et mon choix n’a tenu qu’à ça. Mais comme 3 ans plus tard, je ressens toujours autant de plaisir à coder du Ruby, je me dis que je n’ai pas fait un mauvais choix.
Ça ne veut pas dire que je pense que Ruby est mieux que Python, juste que je préfère Ruby à Python.

Si je devais me lancer dans la découverte d’un nouveau langage, ça pourrait tout à fait être Python, ou bien des langages types Erlang, Clojure, … qui m’apporteraient une nouvelle vision du développement.

Dans votre cas, vous semblez déjà posséder en interne des compétences, apparemment pointues et opérationnelles, en PHP/Symfony. Pourquoi faire fi de cette richesse ?

Si j’étais vous, et si j’avais la visibilité pour le faire, je continuerai à exploiter cette compétence interne (qui fait partie du capital humain de l’entreprise, et une vraie valeur ajoutée à l’heure d’envoyer une réponse à des appels d’offres) et je mettrai en parallèle des ateliers de prise en main sur d’autres technologies, comme Rails mais aussi pourquoi pas comme Django ou d’autres. Ça permet de voir ce qui se fait ailleurs, de s’enrichir, et de changer de point de vue. Ça peut apporter un peu d’air frais, à peu de frais. Et n’empêche pas de mettre en oeuvre concrètement ces technologies sur des petits projets en production pour commencer, pour monter progressivement en puissance au fil du temps ; ça permettrait aussi de pouvoir comparer les technos sur du factuel, avec une prise de risque minimum et très contenue.

Just my two cents.