Un mode de vie
Laissez-moi vous donner un peu de contexte ; au début, cela n’aura peut-être pas beaucoup de sens, mais soyez patients. J’ai grandi dans un pays où l’inflation atteint les deux chiffres. Il y a une course continue entre les salaires et le coût de la vie. Il a connu plusieurs effondrements économiques. Et pourtant, les gens parviennent à mener une vie « normale » ou, du moins, une routine. La seule chose dans laquelle tout le monde dans mon pays est plutôt compétent, c’est la gestion de la dette. J’aborde la dette technique exactement de la même manière et je veux partager cela avec vous.
Le fléau qui s’est abattu sur notre projet
La nature du problème
Il n’est pas rare d’entendre des gens parler de la dette technique comme de quelque chose qui leur est arrivé. Une tragédie qui les a frappés pour des raisons externes. Quelque chose qu’ils ne peuvent pas contrôler et qui était inattendu. Les projets logiciels, du moins ceux qui sont guidés par le profit ou qui s’inscrivent dans le contexte d’une entreprise, sont le produit de deux mondes très distincts. D’un côté il y a l’ingénierie, une discipline qui, avec suffisamment de planification, peut produire une solution adaptée à la plupart des problèmes et qui survivra aussi bien au problème qu’à l’ingénieur. On entend souvent des récits de logiciels anciens tournant sur du matériel qui ne se fabrique plus, fonctionnant toujours, pour des entreprises et des processus disparus depuis longtemps. De l’autre côté, il y a le business, qui est lui aussi traversé par les opportunités du marché et l’élan des tendances commerciales. Essayer d’amalgamer un métier qui peut accroître la qualité de ce qu’il livre en affûtant ses outils et en planifiant aussi longtemps que nécessaire avec un autre qui peut tirer un grand bénéfice d’événements et de livraisons opportuns conduira, presque toujours, à un compromis.
Nous sommes tous sur le même bateau
Une équipe d’ingénierie prendra la mer pour un voyage donné, chargera des provisions et supposera qu’en travaillant pendant le voyage, ce qu’elle doit livrer sera prêt au moment d’atteindre le port. L’équipe business passera le voyage à repérer des ports, à étudier des cartes, à parler aux navires croisés et, à un moment donné, décidera que le prochain port est la nouvelle destination. C’est là que se produit un choc de volontés, où la réalité du business dicte que le meilleur profit sera obtenu si le produit est vendu à mi-voyage. C’est ainsi que naît la dette technique la plupart du temps.
Retour à mes racines.
J’ai été ce marin.
Je ne peux pas dire que cela ne m’est jamais arrivé. Dans notre analogie, je me suis retrouvé à mi-voyage avec les ventes pointant vers le rivage et un demi-produit entre les mains qui avait besoin d’être « achevé » dans un délai irréaliste. J’ai rafistolé avec du ruban adhésif en croyant que j’aurais le temps de le terminer, conformément aux plans d’origine, plus tard.
La réalité déteste les plans
Peu importe à quel point un produit est bien planifié, il changera dès qu’il touchera le client. Penser qu’un plan est si bon que le client recevra un produit qui lui conviendra si parfaitement que l’achever comme prévu est la meilleure voie, est un mensonge que l’on aime se raconter :
- Le temps change le contexte du produit
- Le temps change les clients
- Le contact avec le client crée de nouveaux besoins
Encore des anecdotes
Pour revenir à mon introduction, voici comment nous gérions l’étrange réalité économique dans laquelle nous vivions : en faisant des prévisions sur la façon dont nos revenus allaient suivre l’inflation (le contexte le permet dans une certaine mesure), nous pouvions déduire quels taux de crédit allaient produire une perte nulle et, parfois, même un résultat positif. À un moment de ma vie, il était logique de payer les courses mensuelles du supermarché en 12 mensualités. En utilisant des instruments financiers qui réduisaient le taux d’intérêt en dessous de l’inflation, on pouvait s’attendre à ce que le prix total des biens représente un pourcentage plus faible de ses revenus au moment où le paiement était terminé que si l’on payait comptant. Si cela est difficile à saisir, pensez-y dans le contexte d’une économie plus normale. Vous avez peut-être assez d’argent économisé pour acheter une voiture neuve. Votre banque a peut-être une belle offre où vous pouvez obtenir un prêt pour payer la voiture à faible intérêt. Si vous pouvez imaginer un moyen de faire fructifier votre argent avec, au moins, le même intérêt que le taux de la banque, vous devriez prendre le prêt :
- Vous pourriez trouver un meilleur prêt pour refinancer à l’avenir, ce qui vous ferait économiser de l’argent
- Vous pourriez avoir besoin de cette liquidité plus tard pour de meilleurs investissements ou autre chose et elle serait immédiatement disponible
- L’inflation pourrait dépasser les taux de votre prêt et, si vos revenus le font aussi, votre voiture reviendrait moins cher.
Et maintenant dans la tech
L’explication ci-dessus est assez analogue à ma façon d’aborder la dette technique :
La conception initiale du produit contient une lourde charge d’objectifs et d’intentions business. Il y a beaucoup plus d’apport sur l’effet désiré que sur la solution censée être fournie.
Chaque nouvelle fonctionnalité est planifiée comme si elle devait être terminée au premier port. Sans être négligent (la sécurité et la stabilité sont toujours une préoccupation, la scalabilité pas encore), je prévois de construire la majeure partie de mon produit à partir de composants minimaux et rapides. Une liste de priorités est établie, puis, à chaque port où nous n’accostons pas, cette liste est consommée en complétant des éléments.
Je ne retarde presque jamais la livraison pour achever quelque chose, le mieux est l’ennemi du bien.
Je ne laisse jamais le périmètre croître sans une préoccupation réaliste (encore une fois, la stabilité ou la sécurité). Une fois que quelque chose atteint un client, il est voué à changer, donc moins nous construisons, plus notre travail futur consistera à construire et non à remodeler (ce qui est nettement plus difficile).
Avant de commencer chaque nouvelle fonctionnalité ou gros bloc de travail sur un projet, je vérifie comment la dette existante va affecter le projet en question. Je choisis toujours de payer la dette si elle l’affecte ; un nouveau projet peut servir de refinancement, mais empiler de la dette sur de la dette est une recette pour la catastrophe.
Profitez des éventuels temps morts pour rembourser la dette. Si elle est bien tenue, le grand livre de la dette technique devrait être priorisé. Le critère de tri devrait dépendre de ce qui est important pour l’équipe, mais le temps estimé de correction devrait aussi être calculé. On devrait prendre en haut de la priorité quand le temps le permet, ou simplement résoudre les plus rapides si ce n’est pas possible.
Une heureuse arrivée au port
Pour terminer l’analogie maritime (il est clair à présent que je n’y connais rien en navigation). Cette méthodologie m’a maintenu à flot pendant plusieurs voyages. Je suis rarement surchargé de dette technique. Une façon de penser que j’aimerais utiliser pour conclure ici et qui m’a aidé jusqu’à présent est la suivante : nous ne devrions pas concevoir les projets logiciels comme quelque chose ayant un début et une fin. Je conçois mon logiciel comme si je vendais des contrats de service ; je fournis un service de développement et, si nous sommes en affaires, vous obtiendrez toujours un logiciel frais pour le besoin du moment. Se concentrer sur une livraison périodique aide à apaiser l’anxiété liée à l’achèvement.