Envoyé par
abelar_s
Pourquoi ROR a mis du temps à être utilisé dans les startups et les entreprises ?
Parce que les entreprises ont peur du changement.
"Personne n'a jamais été viré pour avoir choisi IBM."
C'est du business, pas de la techno.
"Parce que les RH ne savent pas l'acheter."
Combien de gens sont embauchés pour faire X et font Y ?
Parce que ton arme secrète... est secrète
Si tu fais du Rails et que ça marche, tu ne vas pas forcément le dire aux autres.
Tu ne veux pas combattre les € rassurants du CAC40 s'ils se mettaient à faire du Rails.
De toutes façons, leur structure fait qu'ils ne peuvent pas forcément accepter l'innovation.
Et puis, tu es occupé à travailler, pas à faire ta pub.
Pourquoi ?
Régie et TJM
Un projet Java ou PHP coûte "moins cher" : tu vires qui tu veux quand tu veux et tu retrouves le même ouvrier peu qualifié à pas cher, surtout en sortie d'école (possible avec Rails, mais pas rentable).
Dans les process que les grosses boîtes se donnent (les achats en premier) c'est cohérent : quand on achète au jour le jour, on cherche à faire moins cher au jour (TJM = Taux Journalier Moyen). C'est pour ça qu'on prend des stagiaires, des juniors, de l'outsourcing... avec les problèmes de qualité et de com que l'on connaît.
C'est la régie, et en cas de dépassement du presta, on accepte que l'on ne trouvera pas toujours du premier coup, mais le risque est porté par le client : si tes codeurs sont en retard, tu les récompense en leur donnant plus d'argent !
=> C'est le combat que se livrent ceux qui sont moyen / bas de gamme.
Vous avez gagné la bataille du prix ? Félicitations, vous avez tué votre marge.
Forfait et TCO
Un projet RoR coûte aussi "moins cher" : plus cher au jour mais significativement moins de jours. C'est l'équivalent d'acheter cher de bonnes chaussures qui font 10 ans, ou 2 paires de trucs pas solides par an.
Dans cette logique-là, tu regardes alors le TCO, Total Cost of Ownership et tu vas compter le dev, mais aussi le déploiement, la maintenance, le coût de la qualité et de l'évolutivité.
Ce n'est pas obligatoirement du forfait : par opposition à tout à l'heure, le risque serait ici porté par le presta intégralement. De plus on aurait un gros cycle en V : tu ne peux t'engager qu'avec l'intégralité du périmètre.
Du coup, c'est plus souvent des lots de fonctionnalités qui permettent de faire des specs légères et itératives, et d'apprendre pour avancer par la suite.
Secret 1 : les gens (qui codent)
Il te faut des gens compétents, auto-disciplinés, capables de bien communiquer sur les enjeux et bien comprendre les besoins. Techniquement ils doivent faire du code évolutif et de qualité, humainement ils doivent aussi être au top. Ils sont aussi plus rares... et avec tout cela, aussi plus chers au jour.
Secret 2 : les gens (qui les gèrent)
Quand tu les embauches, tu as une obligation, pour rentabiliser, de mettre des méthodes plus malines, de former à l'intérieur de l'équipe (ou si ce sont des prestas de t'arranger pour qu'ils forment des gens en interne chez toi), et de capitaliser sur la connaissance.
Ton focus sera différent, tu livres davantage dans le même temps ou pareil mais en beaucoup moins vite. La vraie valeur (je spoile l'histoire) est dans le prototype rapide et itératif, dans l'autonomie que ça donne au métier comme au dev, l'exploration du business model, le droit d'apprendre de ses erreurs...
Ça marche super bien et ça bat les autres projets rien que par le fait d'avoir mis en place une équipe qui a déjà fait sauter les pires barrières à la productivité (possible avec les autres, mais vaut rarement le coup du manager qui met sa réputation en jeu : il faut lui fournir un avantage détonant pour que son chef à lui le laisse casser les barrières).
=> C'est plus rare, mais c'est le combat de ceux qui font du haut de gamme.
Quel avenir pour Ruby on Rails ?
C'est selon le contexte, et il y aura toujours les deux
L'avenir est radieux pour le bas de gamme (pense voitures, chaussures, téléphones) tout comme pour le haut de gamme (idem). La clé est de savoir comment tu te positionnes et d'agir en conséquence : préfères-tu avoir des pièces changeables pas chères et un réseau large de mécanos, ou du haut de gamme tout du long avec plus rare, plus cher, mais vu la qualité un TCO plus faible ?
Bref, je caricature, ça fait longtemps que j'ai jeté cette guerre de religion aux orties.
Il y a du durable en Java mais surtout parce qu'on ne savait pas quoi faire d'autre (à part DotNet). La clé dans tout cela c'est la hiérarchie (et de mon expérience ils en ont marre de prendre les licences que l'écosystème va souvent inciter à prendre).
Hype Cycle, Maturity Model
Les préados qui ternissaient la réputation de Rails sont partis vers Node.
Les startups parties sur RoR ont grandi, on récupère de vrais architectes avec des leçons de plein de langages, plein de frameworks, plein de méthodes (mes préférés sont Arkency et leur super blog). Soit parce qu'elles les récupèrent d'autres technos, soit parce qu'elles les font grandir en interne avec leurs challenges uniques (shopify et github -- regarde leurs talks d'infra), ou enfin parce que des boîtes établies font des parties "en dev rapide" dans Rails (LinkedIn).
En France
Je trouve que RoR va bien en France : 2075 membres à ParisRB, de belles boîtes (Capitaine Train, Drivy, iFeelGoods, Algolia...)
J'ai placé du RoR dans de très grosses boîtes, je sais que d'autres prestas l'ont fait aussi. JRuby est mature et performant, ce qui ne gâche rien.
Bref, je pense que l'on n'a plus grand chose à craindre.
Roadmap
Avec ceux qui partent vers l'essor des frameworks JS MVC front, Rails se retrouve en position de "serveur d'API". Avec ceux qui en reviennent déjà, le rendering côté serveur n'a toujours rien à envier aux autres.
Même avec de la copie, c'est comme toute entreprise/produit : tu veux aller avec le leader ou avec celui qui suit ? Avec celui qui peut et veut se ré-architecturer (il y a des risques bien sûr) ou avec celui qui se coltine un legacy incroyable ? C'est la raison pour laquelle je suis les innovations de la communauté Ruby et de ceux qui en partent (Lotus, Elixir pour l'incroyable concurrence d'Erlang, Haskell pour les fanas de FP).
Bet on the team
Les rubyistes ont pris l'habitude de surprendre et continueront.
Je veux bien regarder les chiffres, mais si Rails rentrait dans le TOP5, ce serait pour moi signe d'une stagnation : avoir une position dominante ne rend pas bête pour autant, mais autorise la flemme ; avoir une position de challenger oblige à se réinventer.
Ruby or not ruby ? 2017 edition
Répondre avec citation
Partager