5 raisons de ne pas faire coacher vos équipes
Parce que les bugs en prod, c'est fun : ça permet de perdre du CA et des utilisateurs 👍
Non, les bugs ne sont pas une fatalité. Un code lisible est plus facile à comprendre, donc à faire évoluer sans causer de régression. Les tests, c'est une évidence, jouent le rôle de filet de sécurité, mais ils peuvent également guider vos développements (Test-driven development). Ayez à cœur d'écrire des fonctions pures, tant qu'à faire, cela facilitera le test et vous évitera la surprise des effets de bord. Enfin, limitez la casse quoi qu'il arrive grâce au Domain-driven design et ses heuristiques de modularisation. Oui, on peut développer sans bug.
Parce que les tests à la main, c'est state of the art, et ça occupe nos longues soirées d'hiver 👍
Faire des tests exploratoires à la main, c'est une évidence. En dehors de ça, tous les autres types de tests peuvent et doivent être automatisés afin d'être exécutés sans erreur et de manière systématique, notamment sur CI : tests unitaires, tests d'acceptance, d'intégration, end-to-end… Plusieurs centaines voire milliers de tests pour un produit. A un moment, l'organisation, le bon-vouloir et la rigueur de chacun ne suffisent plus, il faut automatiser.
Parce que passer mon temps à recruter des devs en remplacement de ceux qui partent (et payer des gens pour ça), c'est chouette 👍
Vos développeurs attendent autre chose qu'un baby foot et des fruits à volonté à la cafétéria. Les développeurs seront fidèles à votre entreprise parce 1. le produit que vous développez a du sens pour eux et 2. pour l'excellence technique et l'apprentissage qui en découle. Aidez-les à progresser et à être fiers de leur travail, ils vous le rendront au centuple.
Parce que ça me va de payer mon logiciel 2 fois plus cher, j'ai trop de budget 👍
Eternel débat du coût de la qualité, mais en fait il n'y a pas débat puisque c'est la non-qualité qui coûte cher (être pauvre, ça coûte cher). Faire du quick & dirty pour un POC, c'est OK et c'est assumé. En revanche, quand on met des moyens et une équipe pour développer un produit pérenne, la qualité est votre meilleure amie. Développer sur une codebase saine, avec une dette technique maîtrisée, c'est la garantie d'une plus grande vélocité. Et non, le pair-programming ou l'écriture de tests ne prennent pas du temps, ils vous en font gagner.
Parce que ça me va de fucker mon time to market et de perdre des parts de marché 👍
J'ai gardé le meilleur pour la fin, puisqu'en tant que CTO, vous êtes là pour faire marcher un business. Nous aimons tous la belle technique, mais elle n'est pas une fin en soi. Ce point est donc la conséquence directe du précédent, et l'on a vu suffisamment de boîtes se faire méchamment doubler à cause d'une dette technique non maîtrisée (coucou Yahoo, coucou Zoom et les autres…). Le TDD, le BDD, le DDD, c'est pas juste pour le plaisir de faire des belles choses, c'est, à la fin, très concrètement, des parts de marché.
Donc si besoin, faites-moi signe 😉