You’re solving the wrong problem

24 June 2013

Paul MacCready et l’anneau de vitesse

La lecture d’un article racontant l’histoire de l’ingénieur Paul MacCready, article que vous pouvez retrouver ici,  a été l’un de ceux qui m’a le plus marqué. Aujourd’hui encore, je raconte cette fabuleuse histoire dans mes formations ou séminaires sur l’Agile. Juste après le Marshmallow Challenge :). Je vous invite d’ailleurs à la lire avant de poursuivre la lecture de ce billet.

Finalement, MacCready n’a fait que s’inscrire dans le principe du « Fail fast, Fail safe« . Sauf qu’il l’a fait pour construire un objet volant, avec une personne dedans, nous démontrant ainsi que ce principe peut réellement s’appliquer partout, si tant est qu’on fasse preuve d’imagination et de bonne volonté.

Redéfinir le problème

Dans cette histoire, qui justifie le titre de l’article, repris pour ce billet, Paul MacCready, s’est intéressé à la façon dont ceux qui l’avaient précédé avaient tenté de gagner le concours. Et Paul en a conclu, de manière assez provocante, qu’ils avaient tous échoué car ils avaient tenté de résoudre le problème posé, à savoir « faire voler un avion propulsé par la seule force humaine ». En réalité, MacCready critiquait le fait qu’on essaye de résoudre le problème de manière trop directe.

La raison pour laquelle je raconte cette histoire juste après le Marshmallow Challenge est, pour moi, évidente. Dans les deux cas, les personnes qui se retrouvent face à leur problème n’ont typiquement qu’une vague idée de la solution qui pourrait marcher. Dans le cas du Marshmallow Challenge, j’ai rarement deux équipes qui partent sur le même type de solution. Alors certes, au fur-et-à-mesure de faire faire cet atelier, des patterns émergent, mais dans la mise en oeuvre, et notamment l’utilisation du scotch et du fil, il y a encore des divergences. Quand je demande si quelqu’un dans l’assistance a déjà mis un marshmallow au bout d’une pate, pour voir comment résiste la pate, évidemment personne ne l’a fait… Il en était de même dans l’histoire de MacCready…

L’apprentissage que j’en retire, c’est que quelque soit le domaine, quelque soit le sujet, si toute la solution ou simplement une petite partie est une inconnue, alors il est nécessaire d’appliquer ce principe de « Fail fast, fail safe ». Quoiqu’il en coûte. Dis avec les termes du Lean Startup, chaque hypothèse doit faire l’objet d’une validation, le plus tôt possible, amenant ainsi à décider de persévérer dans une voie, ou pivoter. Si on imagine une solution parfaite dès le début, ça peut marcher. Mais grâce à un extraordinaire concours de circonstances… Dans tous les autres cas, on aura déployé une énergie folle pour une déception inversement proportionnelle.

Plutôt que d’essayer de résoudre le problème de manière directe, Paul MacCready nous indique qu’il faut redéfinir le problème, ou plutôt résoudre un premier problème, dans son cas : comment créer un avion que l’on peut modifier et refaire voler en quelques heures. Dans le cas du Marshmallow Challenge (attention spoiler ! texte en blanc à sélectionner pour le lire; ne lisez pas si vous n’y avez pas encore joué) : comment peut-on construire un édifice que l’on peut rebâtir en quelques minutes, voire secondes ?

Dans le cas de l’informatique, je le vois de deux façons :

• Sous l’angle fonctionnel : comment peut-on faire pour construire une application que l’on peut mettre en production plusieurs fois par jour ? Et ainsi obtenir le feedback nécessaire pour savoir si on va dans la bonne direction.
• Sous l’angle technique : comment peut-on faire pour construire une application qui ne fonctionne pas que « maintenant », et ainsi allonger sa durée de vie ?

Livrer plus fréquemment

A mon sens, le problème n°1 dans l’échec des projets ce sont les personnes et leurs interactions. C’est peut-être aussi la raison pour laquelle c’est la 1ère valeur du manifeste. La 2nde raison, c’est que les projets sont trop gros. Beaucoup trop gros.

On cherche trop souvent à créer des mastodontes qui mettent des années à être développés avant d’être livrés en catastrophe. La plupart du temps cela se passe en mode panique, puisque comme l’heure de livrer approche (et qu’on n’a pas complètement fini), il faut vite le mettre à disposition pour le tester a minima, et le livrer à la date prévue… Et là, c’est le drame ! Tout s’enchaîne ! Les gros bugs arrivent, des trucs évidents. C’est lent. Très lent. Il faut qu’un développeur assiste l’équipe infra pour faire la mise en production. Au passage, le machin n’est pas scalable : dès qu’on crée deux nœuds load-balancés, ça ne marche pas. Et je passe encore l’insatisfaction des clients qui se rendent compte que le truc fait tout, sauf ce dont ils ont besoin… Il semblerait que d’après certains grands du web comme Amazon, Google et Microsoft, seulement 10 à 30% des fonctionnalités que nous imaginons correspondent à un réel besoin. Bref, c’est un échec. Même si, au final, on a réussi à bricoler un truc… ça tient… comme au Marshmallow Challenge…

Stop ! You’re solving the wrong problem ! Quand vous développez une application, pensez comme Paul MacCready. Redéfinissez le problème : Comment faire pour construire une application que l’on peut mettre en production plusieurs fois par jour ?

Alors vous allez me dire « Mais des applications on en a développé des dizaines ! On sait faire maintenant ! ». Non ! Cette application-là, vous ne l’avez pas développée avant. Pas de ce contexte, pas avec ces spécificités, pas avec ces technos, et pas avec ces personnes. Alors oui, il y a plein de choses que vous savez déjà, et qui à coup sûr vont vous faire gagner du temps. Mais c’était le cas aussi pour MacCready : il savait pertinemment que pour voler, il allait falloir coller deux ailes à l’appareil ! Maintenant, quelle taille devait avoir les ailes ? En quelle matière les construire ? Tout ça sont des questions auxquelles il dû répondre de manière empirique, son expérience l’ayant aidé à trouver la bonne solution après plusieurs essais.

C’est donc mon leitmotiv quand je démarre une application : « Comment faire pour être capable de mettre régulièrement (au claquement de doigts si vous voulez) l’application en production ? ». Cette capacité, associé évidemment au fait de réellement mettre en production régulièrement, est un levier d’apprentissage dont on a tort de se passer. Demain, faites l’expérience : essayez de mettre votre application en production.

Qualité durable

Notre culture dans le développement logiciel est encore très marquée par les approches traditionnelles. Cela se ressent même pour certains projets qui se veulent agiles. Même si on s’organise en itérations, on a toujours en tête le mode de développement usuel, basé sur un développement initial suivi d’une phase de maintenance. Généralement la phase de développement initiale est contrainte par le délai, le coût et, malgré tout, le périmètre. Cette culture nous a amené à livrer les choses à la va-vite, pour que ça marche à la date voulue. Et en bricolant, encore une fois, on y arrive.

Oui mais voilà, une fois livrée, l’application doit vivre… et être maintenue… C’est généralement là que les ennuis commencent : on paye le coût du bricolage effectué, sans lequel on n’aurait peut-être pas respecté nos trois contraintes. J’en ai vu quelques unes des applications qui n’ont même pas tenu une année avant d’être réécrite ! Et c’est l’application, donc les utilisateurs qui en patissent…

Encore une fois, on essaye de résoudre un problème qui n’est pas le bon. Si on se pose une minute et qu’on réfléchit comme Paul PacCready, le premier problème à résoudre est donc de savoir comment faire pour que l’application n’ait pas une durée de vie réduite. Posée autrement : « Comment faire pour construire une application dont le coût de modification reste faible dans le temps ? ».

Voilà pourquoi des principes ou pratiques comme TDD, l’intégration continue, le refatoring, le design incrémental, les pratiques de Clean Code, etc., ont émergé. Elles contribuent fortement à aller dans ce sens. Car une fois ces bases posées, la construction de l’application se fait plus sereinement, sans peur de tout casser. Alors j’entends souvent dire que finalement tout cela est bien gentil, mais franchement, on n’en a pas vraiment besoin… Je pense que ce genre de réflexion est soit prétentieuse, soit égoïste. Je n’ai jamais entendu quelqu’un dire cela en étant totalement convainquant… sauf justement pour des applications qui ont une durée de vie courte. Mais là n’est pas le débat. Si aujourd’hui je considère que ces pratiques sont indispensables, c’est justement pour penser la qualité de l’application dans le temps et non plus sur l’instant. Et si demain de nouvelles pratiques émergent, et vont dans le même sens tout en étant plus performante, oui, je les adopterai.

Un état d’esprit

Certes, les exemples pris, notament dans la 1ère partie, nous montrent que le processus d’apprentissage par l’erreur ne suffit pas. Des compétences fortes, et couvrant tout le champ nécessaire à une réalisation, sont indispensables. C’est indéniable.

Le problème c’est qu’aujourd’hui, j’entends trop souvent dire que ces compétences suffisent, que quelqu’un de bon ne peut pas se tromper… Je n’ai lu que très peu d’histoires sur les génies qui ont marqué les différentes époques, mais tous ont rencontré à un moment donné des échecs, parfois retentissants ! Penser que l’on est capable de faire bien du premier coup n’est qu’une forme de prétention… qui mène au véritable échec : celui de ne pas apprendre. L’expérimentation doit être la norme, et nous en sommes loin. Oui, pour construire une maison, il faut un plan. Mais demandez à un chercheur son planning de recherche de vaccin, avec toutes les tâches à effectuer. Nous ne faisons pas le même métier, j’en suis bien conscient… tout comme le bâtiment en fin de compte… J’ai pris sciemment ces exemples-là, car je pense que dans notre domaine, nous sommes à peu près entre les deux.

C’est un véritable état d’esprit à avoir. Cela ne s’arrête pas à quelques pratiques. Dans le développement logiciel, cela veut dire : livrer plus fréquemment, et adopter des pratiques qui nous donnent un feedback continu sur la qualité intrinsèque du produit.

Si déjà nous arrivions à faire cela, je pense qu’il serait beaucoup plus difficile pour des sociétés de conseil comme SmartView de continuer à vivre.