Loading...En tant que responsable d’équipes de développement, j’ai souvent été amené à quantifier, expliquer et justifier le temps nécessaire à gérer la dette technique : librairies tierces obsolètes ou plus généralement code à « refactorer », ce qui est un terme bien facile pour désigner au choix : code mal écrit, code mort, code à moitié fait, POC jamais utilisé mais jamais supprimé, code pour la démo hyper-importante qui n’a pas été terminé, etc… Tout cela ressemble fortement à du ni fait ni à faire, c’est-à-dire quelque chose dont personne n’assume la responsabilité…
Avez-vous conscience du poids de la dette technique ? Ne laissez pas le code de vos applications s’alourdir inutilement. Faites appel à un CTO pour l’organisation, l’exécution de la roadmap, la méthodologie et les choix d’architecture technique, notamment pour vos projets de développement avec des freelancers.
La dette technique, c’est l’argument pour expliquer que le code a dérivé, que les équipes n’ont pas le temps d’améliorer le code et que c’est finalement normal d’accumuler de la dette technique : les plus physiciens d’entre nous diront qu’il s’agit du comportement normal de tout système entropique.
Doit-on lutter contre l’entropie ? La dette technique c’est un problème technique, non ? Donc laissons les architectes ou les développeurs s’en charger : les plus avancés demanderont simplement d’en faire un backlog, de l’estimer et d’en saupoudrer chaque sprint. Ce sera évidemment dépriorisé immédiatement en cas de besoin.
C’est quoi finalement la dette technique ?
Effectivement, il y a le cas où l’on a oublié de mettre à jour son framework favori: Java, .NET ou PHP mais ce cas est finalement assez facile à identifier et à résoudre. Il y a également le cas où les développeurs de l’équipe ont deux «mains gauches» et il n’y a pas d’architecte dans l’équipe pour leur expliquer ce que sont les principes « SOLID ». Un bon Sonar ou un bon CAST bien utilisés devraient vous permettre d’y voir plus clair. Il peut y avoir des cas vraiment désespérés où le code a vraiment été écrit de travers ou encore même recopié : dans ce cas, il n’y a rien à faire, il faut repartir de zéro (ou partir en courant).
Mais il y a quoi d’autre encore ? Réponse : la dette fonctionnelle (« Functional Debt » pour les férus d’anglicismes à tout crin).
Et c’est là que cela se complique car on entre dans la zone grise. Tout produit avant d’avoir du succès a eu des phases de prototypages, d’expérimentations voire de mise en PROD réelle sans que le produit ou le module en question rencontre de prime abord le succès escompté.
Souvent, on oublie de repartir d’une base saine et de nettoyer / supprimer régulièrement le code. Il n’est pas mal écrit en soi donc ne rentre pas dans la catégorie dette technique mais comme on ne sait plus vraiment pourquoi il est là (sachant que l’équipe a eu un peu de turn-over), on ne sait plus quoi en faire.
Mais c’est qui « on » et comment faire ?
« On » c’est finalement l’équipe qui se rend bien compte que cela ne va pas ou qu’il y a des parties qui semblent ne servir à rien mais que personne ne maîtrise à 100% : en plus « on » a de la valeur à apporter en ajoutant de nouvelles fonctionnalités. Pas le temps de nettoyer et le mammouth prend du poids à chaque sprint, à chaque nouvelle fonctionnalité ajoutée hyper-importante mais finalement pas utilisée ou pas finie. Tout cela finit par rendre les équipes de moins en moins véloces…
Je me rappelle même d’un ancien développeur, passé subrepticement de mon équipe à l’équipe Produit me dire : « Benoit, j’comprends pas : avec 20 développeurs, j’ai l’impression que tes équipes vont moins vite que quand j’étais tout seul avec 2 personnes ».
Comment faire me direz-vous ?
La suite dans le second article… Dette fonctionnelle vs. dette technique – Part #2 : comment identifier la “functional debt”
En savoir plus sur l’auteur, Benoit Fillon
Lisez aussi :
Freelancing, outsourcing, salariat : Comment accéder à la ressource digitale
Vers une pénurie des talents dans les métiers du numérique ?
