Vous pensez mal à la dette technique

« La dette ressemble à n’importe quel autre piège, assez simple pour y entrer , mais assez dur pour partir. »
— Josh Billings (humoriste américain)

C’est l’un des mots les plus sales de la technologie. Comme dans la vie, la véritable référence de l’obligation financière évoque le sentiment d’être alourdi, sous tension. Et sortir de l’obligation financière est une corvée.

En génie logiciel en particulier, la dette technique décrit généralement un système qui vieillit et qui fait perdre un temps précieux aux ingénieurs. La dette technique est quelque chose à gérer, à préserver, à réduire. C’est la dernière chose sur le stock. Cela finira par vous couler.

Faut-il que ce soit cette méthode ?

A Une école d’idées croissante parmi les organisations d’ingénierie progressistes déclare que la dette technique devrait être au cœur du travail de tous les développeurs d’applications logicielles qui, en gérant de manière proactive la dette technique, ces équipes pourraient non seulement empêcher le naufrage, mais peuvent en fait dépasser la concurrence.

Qu’est-ce qu’une obligation financière technique ?

Inventé à l’origine par le chercheur en informatique Ward Cunningham en 1992, la dette technique est le concept selon lequel la création de services à court terme pour les systèmes techniques implique un ensemble de compromis, conduisant à futures responsabilités qui doivent être remboursées sous forme de travail d’ingénierie.

Comme l’a expliqué le concepteur d’applications logicielles Martin Fowler en 2003 :

Dans cette métaphore, faire les choses rapidement et dirty way nous impose une obligation financière technique, qui s’apparente à une dette financière. Comme une dette monétaire, l’obligation financière technique supporte les paiements d’intérêts, qui sont disponibles dans le type d’effort supplémentaire que nous devons effectuer dans l’avancement futur.

Le concepteur d’applications logicielles typique investit plus de 13 heures par semaine consacrées à la dette technique, selon le rapport Designer Coefficient de Stripe de 2018. Aujourd’hui, à mesure que les applications deviennent de plus en plus complexes, la gestion de cette dette n’a jamais été aussi importante. « Tout code que vous avez choisi est une responsabilité est une obligation financière technologique », a déclaré Alexandre Omeyer, PDG de Stepsize, à InfoWorld.

La dette technique prend une grande variété de types. « En bas, il peut s’agir d’un petit emplacement de code qui nécessite une refactorisation, de bibliothèques qui doivent être mises à niveau ou d’un filtrage d’unités qui doivent être réparés », a écrit Isaac Sacolick, écrivain d’InfoWorld, en 2015. « En haut, la dette technique consiste en une réingénierie applications monolithiques complexes, portage de protocoles de services Web obsolètes, consolidation de plusieurs plates-formes en une seule exigence, nettoyage des problèmes d’obligation financière d’information, modernisation des installations, introduction de pratiques d’observabilité ou automatisation d’un stock de cas de test manuels. est une « plate-forme brûlante », indiquant une plate-forme avec des interruptions et des incidents récurrents qui affectent l’entreprise. »

Bien que travailler sur tout ce qui est décrit comme une plate-forme brûlante puisse sembler moins attrayant que de livrer de nouvelles fonctions brillantes, uniquement en attaquant obligation financière technique en tant que groupe, de manière proactive et continue, peut les concepteurs prévenir la douleur à plus long terme.

« Résoudre la dette technique est souvent négligée, car cela répond rarement à un besoin immédiat de l’entreprise et, en particulier pour les cas non urgents, le retour sur investissement est incertain et donc perçu comme reportable », a écrit Sacolick. « C’est un problème classique pour tout, y compris l’entretien, qu’il s’agisse de code ou de maisons. »

Regarder dans l’abîme des obligations financières techniques

Pour Mik Kersten, auteur de Job to Product et fondateur de Tasktop , « La dette technique doit être une chose de premier ordre à assumer de manière proactive. Malheureusement, dans de nombreux cas, c’est un principe nouveau. »

Pour de nombreuses équipes d’ingénierie, en particulier celles en croissance rapide organisations, la dette technique peut donner l’impression qu’elle reste en tension avec le travail crucial de production de nouvelles fonctionnalités. Pour Honeycomb CTO et cofondateur de Charity Majors, l’obligation financière technologique elle-même est « un signe de succès, cela implique que vous êtes toujours en vie ».

Ce n’est qu’en « veillant à ce que les petites choses soient prises en charge que vous pouvez garantir qu’elles ne mûrissez pas pour devenir de gros gremlins », a déclaré Majors à InfoWorld.

Bien que cela puisse être facile à dire, il y a un changement culturel qui doit avoir lieu dans toute l’organisation pour s’assurer que la dette technique est prise sérieusement.

« Être en mesure d’avoir un véritable carnet de commandes prioritaire est un obstacle pour un grand nombre d’entreprises, en particulier celles qui arrivent à un point où elles sont incitées à livrer de nouvelles choses, mais ont tendance à n’ont aucune sorte de récompense particulière basée sur la performance pour gérer leur obligation financière technologique en même temps « , a déclaré l’analyste de RedMonk Rachel Stephens à InfoWorld.

Ou, comme l’a dit Kersten de Tasktop, « En incitant uniquement les fonctionnalités vous mettra dans une spirale mortelle de la dette technologique. »

Comment prendre en charge votre dette technique

John Kodumal, CTO et cofondateur de LaunchDarkly, a informé InfoWorld plus tôt cette année que si « la dette technique est inévitable dans le développement d’applications logicielles », être proactif pour réduire progressivement l’obligation financière est « beaucoup plus sain que d’arrêter d’autres travailler et tenter de se débarrasser d’une montagne de dettes. »

Cette approche proactive pour faire face à l’obligation financière technique comprend le traitement de tout ce que vous pourriez considérer comme une dette technique comme un autre élément de travail à inclure dans votre travail typique procédure agile.

« L’astuce pour préserver les applications et empêcher, ou au moins retarder, le statut hérité, réside dans la façon dont les organisations et les groupes gèrent les obligations financières techniques », a écrit Sacolick. La clé est d’être proactif, ce qui implique : « Développer une politique, une convention et des processus pour amortir le coût de la réduction des obligations financières avec le temps. »

De nombreuses équipes seront tentées de consacrer une quantité spécifique de capacité à prendre en charge obligation financière technique, comme 20% de chaque sprint. Cependant, Kersten de Tasktop conseille d’adopter une technique plus dynamique qui tient compte du contexte des dates d’échéance à venir ou de la capacité du groupe.

« Vous devez déterminer le résultat commercial et l’investissement dans l’obligation financière technologique et vous assurer que ceux-ci s’équilibrent « , a déclaré Kersten. « Rendez la dette technique visible afin que vous compreniez constamment combien vous gérez. Une fois qu’elle apparaît, définissez une partie cible fournie, qui devrait être dynamique au fil du temps. »

Pour Ben Kus, CTO chez la société de stockage en nuage Box, le paiement de la dette technique est quelque chose que tous les groupes d’ingénierie doivent inclure dans leur stock. « Bien sûr, cela est repoussé, mais il devrait y avoir un sentiment permanent que vous vous occupez constamment de ces choses », a déclaré Kus.

Kus ne conseille pas de désigner des ingénieurs spécifiques pour se concentrer sur la dette technique . « Ne l’appelez pas ainsi, c’est de là que l’attrition proviendra », a-t-il déclaré. « Personne ne souhaite travailler sur des obligations financières technologiques, ou refactoriser, des tâches de ce genre. »

Au contraire, chez Box, ils cherchent à répartir le travail de manière égale entre les groupes d’ingénierie et les préoccupations de surface pendant le processus de sprint, en post mortem et sur appel. « Nous avons une procédure post-mortem rigide et nous reconnaissons les choses à corriger pour éviter que les mêmes problèmes ne se reproduisent », a déclaré Kus. « Nous ne sommes pas aussi présomptueux de dire » laissez tomber quoi que ce soit pour réparer quelque chose « , mais nous indiquons clairement que si un problème se reproduit, cela devient un problème de responsabilité. C’est très désagréable si c’est la deuxième fois que quelque chose se produit. « 

La valeur des rotations d’astreinte

Cet élément d’astreinte devient progressivement crucial à mesure que les groupes d’ingénierie cherchent à découvrir et à mesurer efficacement la dette technique qui les ralentit.

Les responsables de l’ingénierie comme Honeycomb’s Majors sont partisans de retirer régulièrement les ingénieurs du travail fonctionnel pour être sur appel et se concentrer sur la réparation, la refactorisation et l’automatisation de cette obligation financière.

« Avoir un ingénieur qui est responsable principalement des petites choses est important. Et dans le cadre de votre garde, vous devriez être activement découragé de faire du travail ponctuel. Cela introduit de la flexibilité dans un système qui en a généralement très peu », a déclaré Majors.

Chris Evans est le fondateur d’Incident.io, une start-up d’applications logicielles alising dans la réaction d’occurrence. « L’intérêt du suivi des choses est de supprimer cette connaissance implicite », a déclaré Evans à InfoWorld. « Vous serez bipé pour des choses que vous n’êtes pas le mieux placé pour gérer. »

Bien que cela puisse sembler effrayant au début, les problèmes seront réparés, puis, en soulignant ce qui a échoué lors des lavages après l’incident ou post mortem, l’importance de gérer cette dette technique peut devenir plus évidente.

« En assumant l’obligation opérationnelle pour le travail que nous effectuons, nous resserrons les boucles de rétroaction entre l’expédition et l’exécution. Cela nous aide à faire des choix d’ingénierie pratiques et à offrir une tension saine entre la livraison de nouveau code et la prise en charge et l’amélioration de ce que nous avons », a écrit Evans dans un article de décembre.

Les ingénieurs d’Incident.io avaient en fait récemment été ralentis par des interactions avec l’une de ses bases de données. »Avec une semaine d’investissement, nous pensons que nous pouvons construire une meilleure méthode pour communiquer avec la base de données, ce qui aura un effet cumulatif sur la façon dont nous développerons chaque fonction à l’avenir », a déclaré Evans.

Et ces succès doivent être célébrés de manière aussi significative qu’un événement important en cours de résolution, ou qu’une toute nouvelle fonctionnalité intéressante débarque, que cela prenne la forme du Tiara of Technical Debt de Charity Majors ou de celui de Mik Kersten commémorant le « meurtre d’une grosse partie de la dette technique comme gagner un tout nouveau client. »

Réévaluer l’obligation financière technique au Financial Times

Le Financial Times a en fait passé les 6 dernières années à remodeler son méthode pour t obligation financière technique. En 2015, le site du journal britannique était propulsé par une application monolithique appelée Falcon. En 2016, les développeurs de l’entreprise ont converti Falcon en un ensemble de microservices, désormais appelé Next dans son intégralité. Les 332 dépôts de code qui en ont résulté sont gérés par un ensemble de groupes durables avec des tâches spécifiées, allant des applications, de la découverte de contenu et des publicités aux plates-formes principales, qui est responsable de 72 dépôts à eux seuls.

« Dans environ un an , les choses avaient en fait commencé à ne pas aller si bien », a déclaré Anna Shipman, directrice technique des produits de consommation au Financial Times, lors de la conférence QCon à Londres en avril.

Les groupes avaient perdu de vue la technologie totale technique et qui possédait quels services. Cela a conduit à une pile croissante d’obligations financières techniques, des « forêts hantées », c’est-à-dire des bases de code orphelines auxquelles personne ne souhaitait toucher et une diminution du nombre d’ingénieurs prêts à être de garde en dehors des heures de travail.

Comme l’un des Les collègues de Shipman l’ont informée : « Il ne semble pas que nous possédions ou dirigeons le système. Nous bloquons simplement des éléments. »

La riposte nécessitait un effort conscient pour passer à l’ordre, en éliminant ceux qui étaient hantés. forêts et accepter la complexité afin qu’elle puisse être gérée plus efficacement. Ce n’est que lorsque les groupes s’appropriaient clairement leurs piles d’innovation que l’organisation pouvait commencer à s’attaquer plus consciemment à ces obligations financières techniques et à ces forêts hantées.

« Ce n’est pas quelque chose à faire avec la prestation régulière de fonctions, c’est quelque chose dont vous avez besoin pour réservez correctement du temps et planifiez du temps pour le faire », a déclaré Shipman. « Ce n’est pas fini. Vous ne vous contentez pas de faire un peu de nettoyage et tout va bien. »

Bien qu’il n’y ait pas de mandat central à attribuer, indiquez, 20 % de tout le temps d’ingénierie pour se débarrasser de forêts hantées et la gestion des obligations financières techniques, Shipman pense que les groupes sont désormais beaucoup mieux équipés pour équilibrer l’expédition de fonctionnalités par rapport à la dette technique.

Génial, maintenant persuadez votre patron

Lorsque vous avez réellement réévalué votre relation avec la dette technique tout au long de l’ingénierie et les développeurs comprennent la valeur de « ralentir » pour faire face à l’obligation financière technique sur une base continue, la difficulté ne s’arrête pas là. Vous devez toujours communiquer cette valeur à la haute direction.

« Les superviseurs de produits et d’ingénierie consacrent leur temps à ajouter de la valeur commerciale, comme si plus de cloches et de sifflets étaient la seule valeur, mais dans certains cas, la valeur la plus importante consiste à régler la voiture », a déclaré Honeycomb’s Majors.

S’attaquer aux obligations financières techniques peut être la première chose à perdre en priorité dans la poursuite des objectifs commerciaux, mais il est nécessaire que les superviseurs de l’ingénierie changent ce récit.

« L’un des griefs les plus courants que j’entends lorsque je parle avec des ingénieurs est qu’ils sentent qu’ils doivent travailler en permanence sur les fonctions, alors que les logiciels et les outils avec lesquels ils traitent deviennent plus fragiles, irréguliers et aggravants et cela finit par être plus difficile et de plus en plus difficile pour eux de faire leur travail », a écrit David Van Couvering, concepteur principal principal chez eBay, dans un article de blog plus tôt cette année.

Traduire fréquemment les menaces de ces systèmes fragiles pour l’entreprise n ont besoin de parler leur langage, en soulignant comment s’attaquer maintenant à la dette technique peut permettre à l’ingénierie d’évoluer plus rapidement à l’avenir, garantir que les logiciels sont plus sûrs et garder les ingénieurs ravis ou les empêcher de quitter la porte.

« Lorsque vous découvrez comment parler comme un costume, votre entreprise, votre équipe et votre avantage professionnel. Votre entreprise en profite car elle évite les échecs qui peuvent provenir de travaux d’ingénierie qui s’accumulent », a écrit Van Couvering.

« D’autres ingénieurs comprendront à quel point ce travail est important. Racontez avec votre partenaire d’entreprise en tant que héros et vous en tant que guide de confiance. Vous devez vraiment vous connecter aux paramètres de l’organisation, comme le délai d’exécution, l’efficacité et la qualité », conseille le Shipman du Financial Times.

Ne prenez pas le risque

Gérer avec succès la dette technique nécessitera déployer beaucoup d’efforts pour changer les cultures et les méthodes de travail profondément enracinées, ainsi que pour améliorer l’interaction entre l’ingénierie et l’entreprise au sens large. les obligations financières sont peut-être existentielles.

« Votre argument contre l’obligation financière technique sera renforcé si vous vous concentrez sur l’aide à l’équivalent de votre entreprise pour comprendre comment les choix d’aujourd’hui augmentent les risques futurs. Parlez de la perte de prévisibilité dans la tâche. Démontrez comment les compromis entraînent désormais une détérioration des performances plus tard », a écrit Rachel Stephens, analyste chez RedMonk, en 2017.

Oui, les nouvelles fonctions brillantes rendent les consommateurs et les dirigeants heureux, mais les systèmes surchargés peuvent tout arrêter et sortir des particules ne semble pas très amusant du tout.