vendredi, 29 mars 2024

Vous pensez mal à la dette technique

« L’obligation financière est comme n’importe quel autre piège, assez simple pour y entrer, mais assez difficile pour en sortir. »
— Josh Billings (humoriste américain)

C’est l’un des les mots les plus sales de la technologie. Comme dans la vie, la référence extrême de la dette évoque des sensations d’alourdissement, de stress. Et se libérer de la dette est une tâche.

En particulier dans le domaine de l’ingénierie des applications logicielles, la dette technique fait normalement référence à un système qui vieillit et qui fait perdre un temps précieux aux ingénieurs. L’obligation financière technique est quelque chose à gérer, à conserver, à réduire. C’est la dernière chose sur le stock. Cela finira par vous couler.

Mais est-ce nécessaire en faisant cela ?

Une école de pensée croissante parmi les organisations d’ingénierie progressistes déclare que la dette technique devrait être un élément central de la travail de tous les concepteurs d’applications logicielles, et qu’en gérant de manière proactive la dette technique, ces groupes peuvent non seulement éviter de sombrer, mais peuvent en fait surpasser la concurrence.

Qu’est-ce que l’obligation financière technique ?

Initialement inventée par le chercheur en systèmes informatiques Ward Cunningham en 1992, la dette technique est l’idée que la construction de services à court terme pour les systèmes techniques implique un ensemble de compromis, conduisant à des obligations futures qui doivent être remboursées sous la forme de travaux d’ingénierie.

Comme le développeur de logiciels Martin Fowler l’a décrit en 2003 :

Dans cette métaphore, faire les choses de manière rapide et sale nous impose une dette technique , qui s’apparente à une dette financière. Comme une dette monétaire, l’obligation financière technique entraîne des paiements d’intérêts, qui sont disponibles dans le type d’effort supplémentaire que nous devons faire dans l’avancement futur.

Le concepteur d’application logicielle typique dépense plus plus de 13 heures par semaine pour régler la dette technique, selon le rapport Designer Coefficient de Stripe de 2018. Aujourd’hui, alors que les applications finissent par être considérablement complexes, la gestion de cette obligation financière n’a jamais été aussi critique. « Tout code que vous avez réellement décidé d’être un passif est une dette technologique », a déclaré Alexandre Omeyer, PDG de Stepsize, à InfoWorld.

L’obligation financière technique prend une grande variété de types. « En bas de l’échelle, il peut s’agir d’une petite zone de code qui nécessite une refactorisation, de bibliothèques qui doivent être mises à niveau ou de tests unitaires qui nécessitent une correction », a écrit l’écrivain d’InfoWorld Isaac Sacolick en 2015. « Sur l’extrémité supérieure, la dette technique consiste en une réingénierie des applications monolithiques complexes, le portage de procédures de services Web obsolètes, la consolidation de plusieurs plates-formes en une seule norme, le nettoyage des problèmes de dette d’information, la modernisation de l’infrastructure, l’introduction de pratiques d’observabilité ou l’automatisation d’un arriéré de cas de test manuel. ‘plate-forme brûlante’, suggérant une plate-forme avec des échecs et des événements répétés qui ont un impact sur l’entreprise. »

Bien que travailler sur tout ce que l’on appelle une plate-forme brûlante puisse sembler moins attrayant que de proposer de toutes nouvelles fonctionnalités brillantes, uniquement en attaquant l’obligation financière technique en tant que groupe, de manière proactive et continue, peut les développeurs prévenir l’inconfort à plus long terme.

« Répondre à l’o La responsabilité est généralement négligée, car cela ne répond presque jamais à un besoin de service urgent et, en particulier pour les cas non urgents, le retour sur investissement n’est pas clair et est donc perçu comme reportable », a écrit Sacolick. « C’est un problème traditionnel pour tout ce qui concerne l’entretien, qu’il s’agisse de code ou de maisons. »

Se pencher sur le vide de l’obligation financière technique

Pour Mik Kersten, auteur de Project to Product et créateur de Tasktop, « La dette technique doit être une chose supérieure à aborder de manière proactive. Malheureusement, dans de nombreux cas, c’est un principe unique. »

Pour de nombreux groupes d’ingénierie, en particulier ceux de organisations à croissance rapide, la dette technique peut sembler rester en tension avec l’important travail de pompage de nouvelles fonctions. Pour Honeycomb CTO et cofondateur de Charity Majors, l’obligation financière technologique elle-même est « un signe de succès, cela indique que vous êtes toujours en vie ».

Ce n’est qu’en « veillant à ce que les petites choses soient prises en charge que vous puissiez vous assurer ils ne mûrissent pas pour devenir d’énormes gremlins », a déclaré Majors à InfoWorld.

Bien que cela puisse être facile à dire, il y a un changement culturel qui doit se produire dans toute l’organisation pour s’assurer que l’obligation financière technique est prise sérieusement.

« Être en mesure d’avoir un véritable stock sur lequel se concentrer est une difficulté pour beaucoup d’entreprises, en particulier celles qui arrivent à un point où elles ont des récompenses pour fournir de toutes nouvelles choses, mais ont tendance à ne pas avoir de récompense particulière basée sur les performances pour gérer leur dette technologique en même temps », a déclaré Rachel Stephens, experte de RedMonk, à InfoWorld.

Ou, comme l’a dit Kersten de Tasktop, « En incitant simplement les fonctionnalités vous vous mettrez dans une spirale mortelle d’obligation financière technologique. »

Comment prendre responsable de votre dette technique

John Kodumal, directeur technique 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 la dette à temps est « beaucoup plus sain que d’arrêter d’autres travaux et d’essayer de sortir d’une montagne d’obligations financières. »

Cette approche proactive pour faire face à la dette technique implique de traiter tout ce que vous pouvez considérer comme une obligation financière technique comme un autre élément de travail à consistait en votre procédure agile habituelle.

« L’astuce pour préserver les applications et éviter, ou au moins retarder, le statut traditionnel, dépend de la façon dont les organisations et les équipes 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 les dépenses liées à la diminution de l’obligation financière dans le temps. »

De nombreux groupes seront incités à consacrer une quantité particulière de capacité à traiter avec obligation financière technique, comme 20% de chaque sprint. Kersten de Tasktop encourage l’adoption d’une approche plus dynamique qui tient compte du contexte des échéances à venir ou de la capacité de l’équipe.

« Vous devez mesurer le résultat commercial et l’investissement dans l’obligation financière technologique et vous assurer qu’ils s’équilibrent », a déclaré Kersten. « Rendez la dette technique visible afin de comprendre en permanence ce que vous gérez. Une fois qu’elle apparaît, définissez une partie cible livrée, qui devrait être dynamique dans le temps. »

Pour Ben Kus, CTO chez Cloud Storage Business Box, le paiement de la dette technique est quelque chose que toutes les équipes 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 attaquez continuellement à ces choses », a déclaré Kus.

Kus ne conseille pas de désigner certains ingénieurs pour se concentrer sur l’obligation financière technique , toutefois. « Ne l’appelez pas ainsi, c’est de là que l’attrition proviendra », a-t-il déclaré. « Personne ne veut travailler sur la dette technologique, ou refactoriser, des travaux comme ça. »

Au contraire, chez Box, ils cherchent à répartir le travail de manière égale entre les groupes d’ingénierie et à signaler les problèmes tout au long de la procédure de sprint, dans les post-mortem et lorsqu’il est sur appel. « Nous avons une procédure post-mortem rigide et nous déterminons les choses à réparer pour éviter que les mêmes problèmes ne se reproduisent », a déclaré Kus. « Nous ne sommes pas aussi présomptifs pour 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 indésirable si c’est la deuxième fois que quelque chose se produit . »

La valeur des rotations d’astreinte

Cette composante d’astreinte devient progressivement cruciale à mesure que les équipes d’ingénierie cherchent à découvrir et à mesurer efficacement l’obligation financière technique qui les ralentit.

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

« Avoir un ingénieur qui est principalement responsable des petites choses est très important. Et dans le cadre de votre garde, vous devez être activement dissuadé de travailler sur les produits. 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 créateur d’Incident.io, un logiciel rtup se concentrant sur l’action d’occurrence. « L’intérêt du suivi des choses est d’extraire cette compréhension tacite », a déclaré Evans à InfoWorld. « Vous serez appelé pour les 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, et après cela, en mettant l’accent sur ce qui a échoué lors des lavages post-incident ou post-mortem, la valeur de la gestion de cette obligation financière technique peut finir par être plus évidente.

« En assumant la responsabilité fonctionnelle du 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 à fournir un stress sain entre la livraison de nouveau code et le support et l’amélioration de ce que nous avons », a écrit Evans dans un article de en décembre.

Par exemple, les ingénieurs d’Incident.io avaient en fait récemment été ralentie par les interactions avec ses bases de données. « Avec une semaine d’investissement, nous pensons que nous pouvons créer une bien meilleure façon de communiquer avec la base de données, ce qui aura un impact cumulatif sur la façon dont nous construisons chaque fonctionnalité à l’avenir », a déclaré Evans.

Et ces succès doivent être célébrés aussi substantiellement qu’un événement majeur en cours de résolution ou qu’une nouvelle fonctionnalité intéressante débarque, que ce soit le genre de Tiara of Technical Debt des Charity Majors ou celui de Mik Kersten célébrant le « meurtre d’un énorme morceau d’obligation financière technique comme gagner un tout nouveau consommateur. »

Reconsidérer la dette technique au Financial Times

Le Financial Times a investi ces six dernières années à améliorer sa méthode d’obligation financière technique. En 2015, le site du journal britannique était alimenté par une application monolithique appelée Falcon. En 2016, les concepteurs de l’entreprise ont transformé Falcon en un ensemble de microservices, désormais appelé Next dans son ensemble. Les 332 dépôts de code qui en ont résulté sont gérés par un ensemble de groupes durables avec des responsabilités définies, allant des applications, de la découverte de contenu et des publicités aux plates-formes principales, qui sont responsables 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 articles de consommation au Financial Times, lors de la conférence QCon à Londres en avril.

Les équipes avaient oublié la technologie générale stratégie et qui possédait quels services. Cela a entraîné une pile croissante de dettes techniques, des « forêts hantées », c’est-à-dire des bases de code orphelines auxquelles personne ne voulait toucher, et une réserve décroissante d’ingénieurs prêts à être de garde en dehors des heures de travail.

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

Combattre a nécessité un effort conscient pour passer à l’ordre, en éliminant ceux qui sont hantés forêts et accepter la complexité pour mieux la gérer. Ce n’est que lorsque les équipes avaient clairement la propriété de leurs piles d’innovation que l’entreprise pouvait commencer à s’attaquer plus sciemment à ces dettes techniques et à ces forêts hantées.

« Ce n’est pas quelque chose à faire parallèlement à l’envoi de fonctionnalités de routine, c’est quelque chose que vous devez réserver correctement du temps et du temps à 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 pour nommer, disons, 20 % de tout le temps d’ingénierie pour se débarrasser des forêts hantées et de la gestion de la dette technique, Shipman pense que les groupes sont désormais beaucoup mieux habilités à stabiliser l’expédition des fonctions par rapport à la dette technique.

Génial, maintenant encouragez votre patron

Lorsque vous avez réévalué votre relation avec une obligation financière technique à travers l’ingénierie, et les développeurs comprennent la valeur de « diminuer » pour résoudre la dette technique sur une base continue, l’obstacle 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 à inclure la valeur de l’entreprise, comme si plus de cloches et de sifflets étaient la seule valeur, mais dans certains cas, la plus grande valeur est régler l’automobile », a déclaré Honeycomb’s Majors.

Gérer la dette technique pourrait être la première chose à perdre en priorité dans la poursuite des objectifs de service, mais il est nécessaire que les responsables de l’ingénierie modifient ce récit.

« L’un des griefs les plus courants que j’entends lorsque je discute avec des ingénieurs est qu’ils se sentent constamment confrontés à des fonctions, alors que l’application logicielle et les outils avec lesquels ils traitent deviennent plus fragiles, irréguliers et décourageants, et cela devient plus difficile et de plus en plus difficile pour eux d’accomplir leur tâche », a écrit David Van Couvering, architecte principal senior chez eBay, dans un article publié plus tôt cette année.

Traduire les menaces de ces systèmes fragiles pour l’entreprise nécessite ng leur langage, en soulignant comment s’attaquer maintenant à la dette technique peut permettre à l’ingénierie d’évoluer plus rapidement à l’avenir, de s’assurer que les logiciels sont plus sûrs et sécurisés et de satisfaire les ingénieurs ou de les empêcher de sortir.

« Lorsque vous découvrez comment parler comme un costume, votre entreprise, votre groupe et votre profession en bénéficient. Votre entreprise en profite car elle évite les échecs qui peuvent provenir de l’accumulation de travaux d’ingénierie », a écrit Van Couvering.

« D’autres ingénieurs comprendront à quel point ce travail est crucial. Racontez avec votre partenaire commercial en tant que héros et vous en tant que guide fiable. Vous devez vraiment vous lier aux paramètres de service, comme le délai d’exécution, les performances et la qualité », encourage le Shipman du Financial Times.

Ne prenez pas le risque

Gérer avec succès les aspects techniques l’obligation financière exigera de déployer beaucoup d’efforts pour changer les cultures et les méthodes de travail enracinées, ainsi que pour améliorer la communication entre l’ingénierie et l’entreprise au sens large. les obligations financières techniques sont potentiellement existentielles.

« Votre argument contre la dette technique sera renforcé si vous vous concentrez sur l’aide à l’homologue de votre entreprise pour comprendre comment les décisions d’aujourd’hui augmentent le danger futur. Discutez de la perte de prévisibilité de la tâche. Montrez comment les compromis entraînent maintenant une détérioration des performances plus tard », a écrit Rachel Stephens, experte de RedMonk, en 2017.

Oui, de toutes nouvelles fonctionnalités brillantes gardent les clients et les cadres heureux, mais les systèmes chargés de dettes peuvent faire trembler n’importe quoi arrêtez-vous, et grimper hors des particules ne semble pas très agréable du tout.

.

Toute l’actualité en temps réel, est sur L’Entrepreneur

LAISSER UN COMMENTAIRE

S'il vous plaît entrez votre commentaire!
S'il vous plaît entrez votre nom ici