Dette Technique et Management
Sur les réseaux sociaux, dans les meetups, il est de bon ton de critiquer le mauvais développeur, et de glorifier le développeur consciencieux, le “clean coder”. Le mauvais développeur arrête la mise au point dès que ça semble marcher. Le bon développeur écrit des tests et refactore son code, en bon artisan. Le mauvais développeur laisse un désordre derrière lui. Le bon développeur laisse le code plus propre qu’il ne l’a trouvé en arrivant.
On en viendrait presque à croire que la clé d’un produit/service réussi c’est de trouver une équipe de “bons”. Avec le bon casting — des champions qui améliorent constamment leur techniques, affûtent leurs outils, et cultivent leur savoir-être — alors vous serez en succès. En cas de mauvaise pioche, votre projet risque fort de finir en retard — s’il finit jamais — et en mauvais état, détérioré par la dette technique.
Or la dette technique, le refactoring, la facilité d’évolution du code : tout cela est l’affaire des managers et non des développeurs.
Pour vous en convaincre, demandez vous qui dans l’entreprise a pour mission de maximiser et préserver la valeur future des investissements d’aujourd’hui.
(Et non, la réponse n’est pas “tout le monde”, sauf dans certaines rares entreprises).
Mais la dette technique, qu’est-ce que c’est ? C’est une incohérence, temporaire ou structurelle, entre votre état de l’art (l’ensemble des procédés, modèles, pratiques, outils, techniques que vous utilisez pour réaliser votre produit) et les objectifs et contraintes qui caractérisent votre projet.
Exemples de DT :
- Pour la démo dans 2 semaines, on a mis les bouchées doubles sur les features clés, mais on n’a pas écrit de tests. On rattrapera après la démo.
- Ce projet au début ce n’était qu’un Proof of Concept, mais au lieu de le mettre de côté pour travailler à la solution industrielle, on nous a demandé de le pousser en production.
- Le cœur de l’appli est en fortran, personne ne sait y toucher; donc on a créé des satellites en R tout autour, ce qui explique tout ces flux de données sur le schéma.
Vous direz : mais tous ces problèmes, ce sont bien des développeurs qui les taclent, au final. Ils sont les seuls à avoir la compétence technique pour ce faire. Ils suffirait juste qu’ils deviennent plus professionnels.
Tout professionnel qu’on soit, pour désendetter un projet, il faut changer les priorités, et adapter l’activité.
Pour changer les priorités et adapter l’activité, il faut prendre des décisions en cohérence avec le Métier. Ces décisions doivent tenir compte des objectifs de l’entreprise, de ses moyens présents et futurs, et de la vision qui préside à ses réalisations.
Voilà pourquoi j’affirme que la dette technique et la facilité d’évolution des réalisations de l’entreprise sont l’affaire de ses managers et non de ses développeurs.