Robert States est un ingénieur mécanique spécialisé dans le design de produits de plastique. Interviewé au sujet de son expérience de partenaire dans la firme de consultation Stress Engineering Services inc., l'ingénieur se décrit comme le personnage du film Pulp Fiction: Winston Wolf. Ce personnage joué par Harvey Keitel appelé d'urgence pour camoufler le résultat d'un meurtre commis dans une voiture par un des personnages principal du film.
"I am Winston Wolfe. I solve problems."
"It's about 30 minutes away, I'll be there in 10."
Lors de cette interview centrée sur le thème de la résolution de problèmes, Robert States souligne les avantages qu'apportent une firme de consultation dans le développement de produits manufacturés destinés à des industries hautement réglementée comme l'industrie médicale.
En tant que développeur de logiciels, ma curiosité a été attisée : est-ce que l'industrie du software aurait des leçons à tirer du processus de design de produits physiques ?
En terme de fiabilité à long terme.
Think hard software!
la philosophie du 'Oui, je connais'
L'avantage d'un consultant expérimenté est d'avoir vécu les mêmes difficultés et les avoir solutionnés à maintes reprises. Lorsque l'ingénieur est impliqué dans le processus de conception, il est en mesure de planifier les étapes critiques ; là où l'équipe va rencontre des difficultés. Surtout son apport en proposant des solutions robustes et éprouvées.
De plus, l'ingénieur propose une approche d'analyse prédictive. Il s'agit du développement de produits physiques basés sur des simulations avancées. Les simulations basées sur des modèles permettent d'améliorer la fiabilité et la précision du produit. Si le produit ne fonctionne pas de la façon prévue, soit le modèle est incorrect soit le produit contient des failles devant être détectées.
quatre anti-patterns de développement menant à des échecs
Robert States énumère quatre façons courantes menant à des échecs dans le développement de produits.
- Quand l'ingénieur demande aux responsables du projet 'Comment en êtes-vous rendu là ?', les parties-prenantes plaident l'ignorance. Ils ignoraient des éléments fondamentaux nécessaire au succès du produit. Plus particulièrement, ils ne savaient pas qu'ils devaient savoir ce qu'ils devaient savoir (!). ('I didn't know I needed to know that...')
- Les parties-prenantes ne s'écoutent pas et ne maintiennent pas un dialogue. Chacun parle de ses besoins sans écouter les autres. Ils évitent de traiter les problématiques soulevées par l'autre parti. En anglais, il utilise l'expression 'talking pas each other'.
- Les équipes tentent sans cesse de réinventer la roue au lieu d'utiliser des solutions éprouvées. Le piège est qu'au lieu de bénéficier de l'expérience de chacun, on impose à chacun une courbe d'apprentissage afin de se mettre à niveau avant d'attaquer le développement du produit.
- Le prototypage rapide amène aussi son lot de problèmes. En présentant un prototype qui 'fonctionne', surtout à des non experts, on s'accorde trop de confiance trop tôt dans le processus de développement.
un anti-pattern organisationnel menant aux échecs
Un taux de roulement élevé au sein d'une organisation est problématique.
Dans une telle organisation, il n'y a personne d'expérimentée connaissant l'historique des projets de l'organisation. Selon Robert States, il est primordial que ces gens expérimentés soient totalement inclus dans le développement de projets afin de transmettre la 'connaissance tribale' aux nouveaux membres de l'organisation.
conclusion: appliquer ces conseils au développement de logiciels ?
Pouvons-nous vraiment appliquer ces conseils au développemenet de logiciels ? Dans un monde idéal, le logiciel est un produit entièrement malléable ne nécessitant qu'une planification minimale. C'est vrai si on a le temps, l'argent et l'énergie de recommencer un projet régulièrement à zéro. Par exemple, le blogue de SocraticDev que vous êtes en train de lire repose sur une solution logicielle : du code sur mesure par-dessus le framework GatsbyJs. Un système de gestion de fichiers de ressources GraphQL. Étonnement le code n'a pas beaucoup changé depuis deux ans. Même si c'est 'juste' du code, il n'en demeure pas moins que ca représenterait un effort conséquent d'avoir à rouvrir le code régulièrement.
Donc, prendre le temps de concevoir une application logicielle correctement dès le départ permet de bénéficier d'une fiabilité accrue et d'un produit qui remplit ses promesses à moindre coût.
