Un ami utilise un logiciel pour le travail. La boite qui fait le logiciel a annoncé que suite à un bug majeur dans le logiciel, ils allaient devoir couper le logiciel le temps de le fix, car les tests n'avaient pas détecté le bug.
Mon ami me demande : "Mais vous faites ça souvent ? Balancer en production sans vérifier ?"
Voici ma réponse :
Constamment.
En gros on teste vite fait l'application, et la majorité du temps les nouvelles versions sont testées qu'à moitié.
Genre on peut sortir une version sur laquelle on a modifié comment fonctionne la carte et les trajets.
On va tester la carte et les trajets, ça marche, nickel.
Mais personne ne va tester la connexion, les affichages d'horaires, etc.
Car ce serait trop chiant à faire à chaque fois.
Il faudrait des tests automatisés, mais là où je suis, on en a pas encore.
Donc on lance en prod un machin à moitié testé, et on est persuadés, la plupart du temps, de n'avoir rien cassé d'autre. Mais du coup, régulièrement... bim, on pète des trucs.
Les nouveaux trucs fonctionnent sans soucis, mais ça a pété un truc qui fonctionnait avant. Et on s'en rend compte que quand c'est en prod. Les utilisateurs sont nos vrais testeurs.
Ce qui conduit à des trucs comme ça

• Mais @Tom, je croyais que t'avais codé un truc pour "tester en amont" et justement éviter les erreurs AVANT de balancer?
• A mon ancien taf, pas ici...
  Car pour coder des tests automatisés il faut prévoir du temps. Environ 20 à 30% de temps de dev en plus.
  Ultra rentable sur le long terme, mais les patrons veulent jamais. Car au final on fait plus de 25% de bugs en général, et plus un projet est vieux, plus ça monte à 50+% de temps de correction des bugs.
  C'est le problème de l'informatique. C'est trop abstrait pour les décideurs.
  Jamais un fabricant de voitures sortirait une voiture sans tester qu'elle roule, qu'elle gère bien un crash test, que les freins marchent, etc;
  Nous on sort une nouvelle version de la voiture chaque mois, et on ne teste qu'un ou deux trucs à la fois. Genre "on a mis quoi à jour ? Le moteur et la vitesse 1 ? Ok vérifions. le moteur tourne ? Le volant tourne ? On peut passer la 1, la 2 et la 3 ? Ok nickel, on la met en vente"
  AKA << Pourquoi le reste ne marcherait pas alors qu'on n'y a pas touché >>
  Sauf qu'un logiciel, c'est une énorme toile d'araignée. Si tu coupes certains fils pour les réaccrocher ensuite, rien ne prouve que t'ai pas cassé d'autres morceaux de la toile en faisant ça !
• C'est juste un problème de génération ? Ou juste des décideurs qui n'y connaissent rien? Je veux dire: est-ce que dans 10ans les décideurs se diront: c'est abhérent de sortir sans tester?
• C'est un problème d'incompréhension, mélangé à un objectif de créer le plus de features "vendables/rentables" en un minimum de temps.
  C'est lié au fait que la priorité dans l'informatique c'est toujours de générer de l'argent au plus vite.
  Dans 10 ans ? Globalement peu de choses auront changé. Au lieu de 0.1% des boites qui font des tests exhaustifs/utiles/maintenus, on aura ptet 0.2 ou 0.3% quoi.
  Le plus souvent, les décideurs n'ont pas le courage de dire "non, on ne rogne pas sur la qualité, peu importe ce que les commerciaux ont vendu".
  La priorité c'est d'accéder aux demandes contractuelles du client.
  Le client veut les features 1 à 14, donc vous devez faire les features 1 à 14. Point.
  On préfère donner au client une version instable et pleine de bugs avec des bugs qui contient ces 14 features, qu'une version ultra stable et testée qui contient que 10 features. Car contrat, engagement, tout ça.
  Et du coup tout le monde est frustré. Nous car on sait qu'on code de la merde.
  Et le client car son logiciel est blindé de bugs.
  L'informatique c'est un truc ultra instable.
  T'as une machine, qui fait tourner un OS. Cet OS fait tourner un framework. Ce framework fait tourner ton logiciel. Ton logiciel utilise d'autres logiciels. Ton logiciel appelle d'autres machines. Ton logiciel utilise d'autres plugins. Pour développer ton logiciel, tu utilises un logiciel spécifique.
  Chacune de ces étapes est instable et peut avoir des soucis. Il suffit d'un bug sur un logiciel et tout le reste part en carafe.
  En plus, quand, en tant que dev, on doit estimer un sujet, ben on oublie tout ça. On estime "ok une journée pour ça, une journée pour ça, et une journée pour ça, donc 3 jours".
  Sauf que t'as pas calculé qu'un logiciel plantera. Qu'un autre sera incompatible avec un prérequis. Que le besoin client sur un point précis changera pendant ces 3 jours. Que le serveur aura pas la bonne mise à jour pour un des plugins. Etc.
  Du coup tes 3 jours deviennent 6, et t'as fait du code crade.
  Mais du coup, les patrons sont frustrés car "putain les développeurs ça sait pas tenir une estimation !"
  Perso j'ai une règle ultra simple dans l'informatique. Tu dois estimer un truc ? Tu estimes honnêtement combien de temps il te faut pour le faire.
  Ensuite tu fais x2 pour une estimation réaliste et réalisable.
  Et si tu veux faire du code propre, tu fais x3.
  J'ai testé pendant des mois, et je tombe juste à chaque fois... C'est imparable. Les devs sont trop optimistes. Les patrons sont beaucoup beaucoup trop optimistes.
  Mais le problème c'est que les patrons sont dirigés par le besoin d'argent, de sortir plein de features rapidement, et ne voient pas le coût long terme des bugs. Jamais.
  Ils priorisent en fonction de ce qui serait le plus préjudiciable à court terme. "Ce contrat est critique, mais ce bug peut nous couter plus cher, on va d'abord le traiter, puis on ruchera les features du contrat pour rester dans les clous."
  Ajoute à ça un domaine ultra abstrait, où même ceux qui bossent dessus oublient régulièrement tous les aléas... et voilà.
  Le patron pige pas pourquoi un dev bidon peut prendre 1 semaine.
  Le dev comprend pas pourquoi son dev estimé à 4 jours en a pris 8.
  Le client pige pas pourquoi le truc reçu a plein de bugs.
  Le patron pige pas pourquoi les clients changent de prestataire car nos solutions sont trop instables.
  Le client pige pas pourquoi le nouveau projet qui leur a couté 2M€ est aussi instable que le précédent.
  Bis infinita.