Lorsque j’ai découvert et intégré TDD à mon travail, je disais à qui voulait l’entendre que c’est un moyen efficace et motivant de produire du code propre et qui marche. Et ceux qui voulaient l’entendre de répondre aussitôt :

— Oui, mais :

  • ça fonctionne seulement pour les petits projets
  • ça fonctionne seulement pour les grands projets
  • écrire autant de tests c’est de la sur-qualité
  • ça double le volume de code produit sans vraie valeur ajoutée
  • d’ailleurs les tests testent le code, mais qui teste les tests ? Ça ne s’arrête plus
  • on ne peut pas non plus refactorer à l’infini, à un moment il faut produire
  • quelques tests d’intégration ça fait largement l’affaire
  • un développeur qui cherche à casser le code qu’il construit risque de devenir schizophrène
  • les tests, c’est pour les gens qui ne savent pas coder

C’est de bon aloi : j’essayais de les persuader d’essayer TDD; en retour ils essayaient de trouver des raisons pour ne pas l’essayer.

Mais la meilleure raison de ne pas essayer TDD, on n’a pas besoin de la chercher en examinant mentalement tous les tenants et aboutissants théoriques de la démarche. Cette raison est simple, universelle, imparable : on n’a pas le temps. ⌛️

En général le budget d’un projet de développement logiciel qui démarre est plein comme un œuf. Vous y trouverez à peine de la place pour les aléas. Pour peu que l’estimation soit sujette à des variations selon les hypothèses, on retiendra l’hypothèse la moins chère, pas la plus probable. On sait d’expérience que des problèmes de qualité surviendront, et on les a même provisionnés, parfois en gonflant certaines estimations.

Tous ces systèmes sur lesquels on trouve beaucoup de tickets d’incident et peu de tests, sans même parler de la documentation, ce n’est pas que leur développement était sous financé : il s’est mis en retard et a utilisé toute la provision. 💸

A l’exception peut être de contextes de purs projets de recherche, aucune équipe ne conclut le cadrage d’un projet en déclarant :

“Il se pourrait qu’on découvre chemin faisant des opportunités de mettre en œuvre une démarche qui réduirait les problèmes de qualité tout en nous faisant gagner du temps. Si le cas venait à se présenter, nous n’hésiterons pas à marquer une pause sur l’avancement du projet afin de se donner le temps d’acquérir et d’intégrer une telle démarche.”

Non, s’il fallait résumer la conclusion d’un cadrage de projet en passant le micro à chacun des 3 acteurs cela donnerait :

🎤 Métier : J’ai hâte que ça démarre enfin, parce qu’on n’est pas en avance. ⏱

🎤 Tech : Rassurez-vous ! Vous avez pris les meilleurs ! 🎯

🎤 Management : C’est tendu, mais on va voir ce qu’on peut faire. 🧩

Pour améliorer son état de l’art, une entreprise à le choix :

  • emprunter un état de l’art qui n’est pas le sien, mais qui fera illusion le temps du projet 🎯
  • manager en enseignant, de haut en bas dans l’entreprise, une démarche d’amélioration continue ⌛️

Stay Tuned ! publié sur Linked In le 02/05/2023