Après le slow food, le slow computing ?

Depuis l’ouvrage “The Lean Startup” qui promeut l’amélioration et l’innovation en continue au coeur de l’organisation des start-ups grâce à l’adoption d’une démarche itérative, depuis l’explosion de l’adoption de la méthode SCRUM qui propose un découpage itératif du développement, une organisation destinée à améliorer l’autonomie de l’équipe de dév. et à améliorer la vélocité et donc le rythme d’ajout/livraison de nouvelles fonctionnalités, l’industrie informatique a réellement et profondément changé de rythme.

image

Alors qu’il y a quelques années, mettre en place des builds afin d’avoir une nightly build destinée à vérifier la validité/cohérence du code présent dans un repository était “hype” et synonyme de démarque qualité, nous sommes à présent nombreux à avoir mis en place de l’intégration continue, à compiler et à tester de manière automatisé dès qu’une modification est commitée.

De même que cela soit via la mise en place de Continuous Delivery ou encore de Continuous Deployment, le rythme de livraison s’est effectivement accéléré dans de nombreux projets.

Les utilisateurs ont donc le grand bonheur de bénéficier d’un plus grand nombre de nouvelles fonctionnalités, plus pertinentes, et ceci beaucoup plus rapidement !

Achievement unlocked !

Tout cela est positif, mais cette course vers la nouveauté a malheureusement un coût et de plus en plus de personnes commencent à se plaindre.

Exemple le plus récent, le projet Docker qui, que cela soit via ce post de blog controversé (lire les commentaires, et les posts de blog en réponse, cité par l’auteur), ou alors encore via ce feedback récurrent d’avoir un rythme d’évolution plus lent afin d’être en capacité de faire évoluer son infrastructure tout en bénéficiant des derniers correctifs.

Autre exemple d’impact bien plus mineur, le Bot Framework dont la V1 a été rendu disponible le 1er Avril 2016 et qui moins de 6 mois plus tard contient plusieurs nouvelles versions et une V3 contenant des breaking changes et nécessitant donc une migration de code (migration qui au passage ne fonctionne pas correctement et qui impose donc la réécriture de ses bots à partir d’un nouveau projet “from scratch”). Exemple de changement : On vient de changer le nom de ces classes, désolé, on n’avait pas assez réfléchi au nommage de nos classes, et avec le recul on trouve que les nouveaux noms sont plus pertinents.

Inimaginable dans le monde Microsoft il y a quelques années, avec une stratégie basée sur une compatibilité maximale de l’ensemble des produits, ce type d’évolution est en train de devenir de plus en plus courant.

Il est donc important de bien réaliser que le gain apporté par des itérations rapides peut se transformer en coût pour le développeur ou l’utilisateur final.

On parle ici de coût induit par du travail supplémentaire nécessaire pour supporter les nouveautés/évolutions on peut également évoquer les pertes sèches causées par l’achat de produits hardware.

Alors qu’auparavant acheter des produits et services de grandes sociétés renommées permettait d’être à peu près à l’abri de l’abandon de ceux-ci et de bénéficier d’une durée de vie plus longue que d’autres produits de sociétés moins établies, il est nécessaire d’oublier ce vilain reflexe.

Les grands éditeurs et constructeurs se placent en effet de plus en plus tôt sur la courbe d’adoption afin de maximiser les chances de prendre une part conséquence de marchés qui sont régulièrement de type “the winner takes all”, et le risque d’abandon ou d’échec est donc beaucoup plus important qu’auparavant.

Il n’y a qu’à juger la stratégie Hardware de Microsoft décrite au sein de cette excellente interview de Mary Jo Foley. Terry Myerson y indique clairement que la stratégie de Microsoft est d’essayer d’ouvrir, animer, dynamiser différents marchés hardware, et de montrer à leurs potentiels partenaires qu’ils sont sérieux sur ces différents marchés, en construisant lui-même des devices sur chacun de ces marchés.
Les casques/lunettes de réalité virtuelle sont cités en exemple dans cette interview mais on peut citer plusieurs exemples à ce sujet : les tablettes et notebook Surface destinés à montrer aux constructeurs qu’il est possible de faire des devices sous Windows d’aussi bonne qualité et aussi beau qu’Apple, Microsoft Band destiné à montrer ce qu’il est possible de faire de lien d’un point de vue hardware et software avec Microsoft Health d’un point de vue des objets connectés (wearables) lié à la santé.

Votre côté geek vous incite à acheter certains de ces nouveaux devices, et vous râlez sur le fait qu’ils ne soient commercialisés qu’en petit nombre et uniquement dans certains pays ? Peut-être que vous devriez y réfléchir plus longuement avant de potentiellement jeter votre argent par la fenêtre Clignement d'œil

Bien évidemment la solution pour ne pas tomber dans ces écueils n’est pas de ralentir le rythme d’innovation comme pourrait le sous-entendre le titre de ce post.

Il existe différentes pistes, et je suis convaincu qu’un ensemble de bonnes pratiques seront prochainement publiées en ce sens :

  • Etre clair sur sa communication
  • Proposer différentes cadences de livraison afin que chacun puisse s’adapter en fonction de son souhait (ex : Windows avec le programme Insiders et les fast/slow rings, .net où l’on peut récupérer des packages nuget de versions récentes ou utiliser le framework .net livré avec Windows, etc.)
  • Développer des correctifs pour plusieurs versions supportées en parallèle
  • Proposer un outillage de plus haut niveau qui facilite la gestion de tous ces changements. Exemple : solutions de management d’APIs

Une réflexion au sujet de « Après le slow food, le slow computing ? »

  1. Ping : Petit guide pour râler de manière constructive - Blog de Patrice Lamarche

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *