Pourquoi le time-to-market n'a-t-il pas gagné ?

david_b · Février 10, 2018, 2:18

Je suis revenu à une stack Ruby on Rails l’an dernier, et en terme de “time-to-market” c’est incomparable. Dans le passé j’ai fait du Java, du Node, du Ember, du React, etc, sans arrêt le dernier truc à la mode… et force est de constater que Ruby on Rails n’est toujours pas vaincu en terme de “Get Things Done”. Je délivre beaucoup plus de feature, avec beaucoup plus de qualité avec ce bon vieux RoR qu’avec n’importe quelle autre stack plus récente, ce qui est curieux. J’ai un peu de VueJS quand la logique front devient vraiment trapue, mais à part ça…

Je reconnais qu’en NodeJS, les tests et le hotreload sont hyper rapides, mais, à la fin de la journée, même avec des tests plus lents, et un hotreloading moyen, je termine plus de choses en RoR qu’avec une stack récente.

J’en viens à ma question : pourquoi l’évolution des outils n’est elle pas allé vers un “Time-To-Market” toujours plus important, ce qui est quand même une finalité de l’informatique ?

abelar_s · Février 10, 2018, 3:28

Je pense que le “time to market” que tu décris est possible avec une grande implication… de tous les autres métiers.
“Du métier” bien sûr, comme on dit, les gens qui savent faire tourner le business que ton outil informatique va soutenir, mais aussi de tous les autres : ceux qui encadrent, ceux qui décident, ceux qui font les métriques, ceux qui font, vendent, livrent les produits ou services qui vont avec, etc.

… que cet alignement des planètes est rare… Tout le monde le cherche, tout le monde le veut, tout le monde pense que c’est une question de survie d’être plus rapide et plus efficace, et beaucoup ont l’impression d’être le moteur de la voiture tandis que les autres sont les poids morts.
C’est très vrai des jeunes devs arrogants, et c’est aussi ce que pensent les autres corps de métier de beaucoup de devs.

… mais que tout le monde n’est pas prêt au changement culturel nécessaire pour que ça arrive.

certains sont trop “la tête dans le guidon” pour chercher mieux
certains ont trop de freins DANS leur équipe pour changer (“ah non, on change pas ma stack favorite”, diraient les devs – “ah non, on change pas le rythme de travail”, diraient d’autres services – “ah non, on va pas me demander d’ajouter/retirer tel truc de mon périmètre” diraient d’autres encore)
certains ont trop de freins HORS de leur équipe pour changer (les mêmes qu’au-dessus, sauf qu’en plus la hiérarchie fait que tu n’as pas forcément la facilité pour communiquer avec eux, ou leur hiérarchie)

Tu peux poser ta question sur tous les autres sujets : pourquoi tout n’est pas numérisé, pourquoi tout le monde n’est pas Agile, pourquoi… et bien, je dirais que :

bien sûr, déjà, il y a plusieurs réponses à la même question : le Time to Market oui, mais est-ce que ça impliquer forcément Rails ou parfois un produit sur étagère ? Acheter tout prêt ou construire, il faut choisir
il faut choisir le meilleur outil pour le job en fonction des contraintes, et surtout des gens que tu peux trouver : ce n’est pas de la productivité, c’est un mélange entre l’historique et les habitudes, entre la mode et la com
l’uniformité, les habitudes rassurent : on ne peut pas changer tout le temps
c’est facile de se mentir à soi-même : il est très simple d’être enlisé et de croire qu’on avance (exemple : je respecte les rituels Scrum mais pas du tout les valeurs Agile ? pas grave, je peux m’appeler Agile et donc je n’ai pas besoin d’être “plus Agile” ou “Agile différemment”) surtout quand la revue de performance de quelqu’un dépend du fait que les cases sont vertes (sans pouvoir regarder sous le tapis) et non rouges (mais pour avancer vers un meilleur objectif). C’est la différence entre les valeurs que tu annonces, et celles que tu appliques… et “de qui est-ce le job ?”

Bref : le changement est inconfortable, la vérité est inconfortable.
Lancer (je ne dis même pas réussir : je dis lancer) un changement qui met plus de 10 à 100 personnes dans un inconfort est… compliqué.

PS : un jour prenons le temps de discuter comment aller encore plus vite que Rails ;)

hlassiege · Février 10, 2018, 5:57

Pour donner un peu de contexte, j’ai utilisé professionnellement C, PHP, C++, Visua Basic, C#, Embed Visual C++, Java, Python, Javascript.
Dans chacun de ces langages il y a le petit truc qui fait aller vite, parfois intégré dans le langage, parfois c’est lié à l’écosystème.
Mais parler techno sans finalité c’est déjà prendre le parti pris que tout se résume à faire du web, ou du client lourd, du système embarqué ou que sais-je encore.
Ces technos ont des points forts et des faiblesses.
Je vais citer une personne qui a écrit cela en 1980, “there is no silver bullet” (https://fr.wikipedia.org/wiki/Pas_de_balle_en_argent). Le même type qui a écrit “the mythical man month”.
Et on va en reprendre une partie de l’essence de cette citation dans cette conférence que je t’invite à regarder : https://www.youtube.com/watch?v=3wyd6J3yjcs

Oui, en ROR il existe sans doute un “sweet spot” ou le framework démontre toute sa puissance. D’ailleurs des frameworks dit “haute productivité” on pourrait citer aussi Django ou même, selons leurs auteurs tout du moins : revel, jhipster et j’en passe.
Peut être que le marché n’a pas toujours adopté ces techniques pour de multiples raisons :

parce que ces technos ne sont pas transposables dans tout les contextes (faire du trading haute fréquence en ROR ? hum, non)
parce qu’il faut trouver les personnes peut être ? Ne pas négliger le côté recrutement et formations
parce que c’est lié a une communauté. Peut être plus difficile de trouver des users groups ou des conférences sur certaines technos, donc moins d’émulation locale. Peut être moins de doc ou d’aide en ligne etc…
parce qu’acculé dans ces derniers retranchements, une fois sorti de ce “sweet spot”, il se trouve que 95% des technos finissent toujours par lutter contre le développeur au lieu de l’aider.

Bref, si tu es à l’aise avec ROR, fais en, profites-en. Garde juste les yeux ouverts, parfois les problèmes changent et quand on n’a qu’un marteau… tu sais ce qu’on dit.