Ouarzy's Blog

(English version available here)

Il y’a quelques mois, j’ai eu la chance de proposer par l’intermédiaire de Florent Pellet un Brown Bag Lunch chez CEGID sur le sujet du BDD. La présentation était assez proche de ce que j’avais fait lors du 1er Human Talk de Lyon.

Et à la fin,  j’ai eu cette question qui m’a un peu surpris :

«Ok, c’est bien beau tout ça, mais combien ça coute si on veut le mettre en place? »

Sur le principe, la question n’est pas choquante, mais j’ai compris à ce moment-là que j’étais perçu par cet interlocuteur comme un marchand de tapis venant lui vendre de la prestation. Alors que je me plaçais vraiment dans le partage de mon expérience sur le BDD qui me permet aujourd’hui de mieux travailler au quotidien.

Ma réponse a donc était « Ça ne coûte rien d’autre que l’énergie nécessaire pour comprendre la méthode et pour utiliser l’outil  SpecFlow dans votre cas»

On m’a répondu « Ah bon ? C’est juste une question de choix alors ? »

Exactement ! C’est le choix de travailler mieux.  Et c’est ce qu’on se tue à répéter en tant qu’artisan développeur. Faire du TDD, du BDD, du DDD, avoir un serveur de build, travailler en intégration continue voir en déploiement continu, bref travailler sereinement, c’est un choix.

Le corollaire étant que travailler sous la pression, être pris pour un pisseur de code sans savoir-faire, enchaîner des journées de 12h et ne pas être fier de ce qu’on produit, c’est aussi un choix.

Et si je me permet cette affirmation aujourd’hui, c’est parce que moi aussi j’ai commencé par travailler dans de mauvaises conditions, en essayant de me convaincre que je n’avais pas le choix. Le TDD c’était beau sur le papier, mais ce n’était pas possible « dans la vraie vie ». Parce qu’après tout, chez nous c’était différent ! On avait des clients impatients et mécontents, des deadlines très serrées, bref, on n’avait pas le temps.

Puis un jour (la lecture de clean code m’ayant servi d’électrochoc), j’ai compris que si je me mettais à tester mon code, à essayer de travailler en TDD, personne ne pourrait m’en empêcher. Ok, j’avais déjà essayé d’en parler autour de moi sans succès, mais est-ce que c'est une raison pour ne pas le mettre en place sur mon travail ? Non. J’ai donc commencé à produire des nouveaux modules testés. Je me suis renseigné sur la gestion de code legacy, et la meilleur architecture à utiliser pour avoir un code testable en Silverlight. J’ai très rapidement vu la différence : j’avais des millions de nouvelles questions !

J’ai évidemment souvent douté, j’ai même accepté de développer un produit complet sur plus de 6 mois sans aucun tests ! (Après tout le proto fonctionnel avait été produit en 1 semaine, on ne peut pas imaginer qu’il faille plus de 6 mois pour transformer cela en produit… Et puis c’était très dépendant d’un SDK, alors c’était quand même très compliqué à tester…Bref, on trouve toujours des excuses !). Je m’en mords encore les doigts, et ça aura été la dernière fois. J’ai démissionné peu de temps après. J’ai choisi que désormais, je ne travaillerais que sur des projets au moins testés.

Je me suis donc mis à mon compte, et devinez quoi ? Je gagne plus, je travaille moins, je suis fier de ce que je produis, et j’ai plus progressé en 1 an et demi de ce régime que pendant mes 3 années précédentes.

Mais comment rentrer dans ce cercle vertueux de l’amélioration continue ? En tant que développeur, je vous suggère ces 2 points de départ :

-        Faite de la veille (blog, twitter, formation, conférences…) pour savoir comment tester votre code

-        Et testez votre code

A partir de là tout s’enchainera naturellement : pour bien tester il vous faudra écrire du meilleur code. Quand votre code sera meilleur vous chercherez à améliorer vos tests. Quand les 2 seront de niveau acceptable vous pourrez réfléchir à une usine logicielle plus performante (serveur de build, déploiement continue ?). Ensuite vous pourrez rendre votre équipe plus productive car vous serez beaucoup moins ralenti par les détails techniques du quotidien. Vous deviendrez vous-même meilleur en passant plus de temps à apprendre. Au final, c’est votre client qui vous remerciera au lieu de râler à chaque nouvelle version (à juste titre, puisque jusque-là nouvelle version  équivaut à nouveaux bugs). Ayant moins de pression de vos clients, vous pourrez passer plus de temps à améliorer votre code… Et ainsi de suite.

Si votre façon de travailler ne vous convient pas, hackez votre travail, changez vos méthodes, changez d’employeur si c’est la seule solution !

Don’t panic, just hack your job.