Comment puis-je convaincre la direction de gérer une dette technique?

C'est une question que je me pose souvent lorsque je travaille avec des développeurs. Jusqu'à présent, j'ai travaillé pour quatre entreprises et j'ai pris conscience du manque d'attention portée à la propreté du code et au traitement de la dette technique, qui entrave les progrès futurs d'une application logicielle. Par exemple, la première entreprise pour laquelle je travaillais avait écrit une base de données à partir de zéro plutôt que d'utiliser quelque chose comme MySQL, ce qui a créé un enfer pour l'équipe lors de la refactorisation ou de l'extension de l'application. J'ai toujours essayé d'être honnête et clair avec mon manager quand il discutait des projections, mais la direction ne semble pas intéressée à réparer ce qui existe déjà et c'est horrible de voir l'impact que cela a sur le moral de l'équipe.

Que pensez-vous de la meilleure façon de résoudre ce problème? Ce que j'ai vu, ce sont des gens qui font leurs bagages et qui partent. La société devient alors une porte tournante dans laquelle les développeurs entrent et sortent et aggravent le code. Comment communiquez-vous cela à la direction pour qu'elle s'intéresse au règlement de la dette technique ?

Quand j'ai rencontré mon patron pour en discuter, il m'a dit que je devrais inclure le refactoring dans tous mes devis. Il a dit que ce n'est pas un problème auquel il veut penser. Au lieu de cela, je devrais le gérer.

Ce n’est pas un problème auquel la direction en général veut réfléchir. Ils ne sont pas les ingénieurs, vous êtes. Faites simplement de ceci une partie inexprimée de toutes vos estimations et vous constaterez que la dette technique diminue.

Ce ne sera jamais parfait cependant. Les dettes techniques, comme les dettes de carte de crédit, représentent un investissement permettant d’obtenir des clients plus rapidement et d’accroître plus rapidement leur part de marché par rapport à leurs concurrents. Comme le crédit, s'il est géré correctement, il peut vous aider à réussir.

C'est comme Gandhi a dit lorsqu'on lui a demandé si sa tactique fonctionnerait avec quelqu'un comme Hitler. Il a dit: "Ce serait difficile." Mais je pense qu'il y a un bon argument que la réponse est vraiment "Non" Malheureusement, je ne pense pas que ce que vous essayez de faire puisse être fait. Ce n'est pas que j'essaye d'être pessimiste, mais plutôt d'être honnête.

Le problème pour moi n’est pas que les gestionnaires aient besoin de convaincre. Les meilleurs comprennent déjà que la dette peut tuer si elle n’est pas gérée. Mais qu’ils le comprennent ou non, qu’ils soient de bons ou de mauvais gestionnaires, ils doivent tous faire face à des pressions pour que les choses soient livrées, et cette décision est jugée par leur supérieur hiérarchique. La qualité n'a d'importance que si elle est extrêmement mauvaise, auquel cas c'est la faute des développeurs ou extrêmement bonne, auquel cas c'est le génie de la gestion qui a rendu cela possible. La qualité doit simplement être "assez bonne".

Je pense que j'aime bien ce que Renesis a dit dans sa réponse, car c'est l'un des rares à comprendre que la direction pense très différemment de l'ingénierie. Et je pense que nous avons tous vu la progression des entreprises devenir de plus en plus axées sur la date et la gestion de projet, par opposition à la clientèle et à la qualité. Par cela, je veux dire les entreprises typiques, pas les entreprises vraiment fortes qui ont le courage de dire "ça sera fait quand ce sera fait" (comme Apple Computer ou id Software - et oui, je comprends que parfois les gens ne sont pas en liberté prendre cette approche).

Mais voici le problème: les entreprises qui privilégient la qualité d'abord: que remarquez-vous à leur sujet? C'est vrai, ils sont dirigés par des ingénieurs et non par des vendeurs, des spécialistes du marketing, des chefs de projet ou des comptables. Pensez à HP, Apple, id, Google, Microsoft et IBM. Ce sont tous des ingénieurs, et non des vendeurs, qui ont démarré et qui ont connu du succès, bien que les vendeurs aient certainement joué un rôle, et je suis sûr que beaucoup discuteraient de l’association de Microsoft à la qualité :). Et parmi ceux-ci, ceux qui sont tombés en panne ont échappé à un leadership axé sur l'ingénierie. Cette déclaration contient cependant une foule d'arguments, car de nombreuses entreprises techniques ont finalement échoué en raison de leur incapacité à s'adapter à l'évolution de la situation et à gérer leur propre croissance. Je ne vois pas le leadership basé sur l'ingénierie comme la cause de ces échecs, pour moi ça ' s un problème de compétences et de sens des affaires qui ne dépendent pas du développeur ou du comptable. Je pense toutefois que, d’une manière générale, l’ingénierie se consacre aux rigueurs de la responsabilité et de la discipline qui profitent aux entreprises dont l’ingénierie est un élément.

Sérieusement, regarde autour de toi. Le leadership informatique fait cruellement défaut. L'accent est toujours mis sur les coûts et les délais, et rarement sur la qualité tant qu'elle est suffisamment bonne. Les responsables informatiques ne font plus que rarement rapport au PDG, à présent, il s’agit toujours du CFO. L’informatique est bloquée dans l’aide à la production et de plus en plus redevable à des chefs de projet qui se concentrent sur des morceaux plus petits, plus digestibles et mesurables, et non sur des changements significatifs de valeur révolutionnaire doit être là pour la grande image).

Désolé de prendre si longtemps sur ce post, mais au final, je pense que votre question, concernant la gestion de la dette technique par la direction, est souvent mieux résolue en trouvant le bon dirigeant, plutôt que de changer celui existant. Expliquer la dette technique aux penseurs ordinaires signifie changer l’attention portée à l’argent et aux coûts, comme l’a dit Renesis, et je pense que cela perd beaucoup en traduction; même si vous y parveniez, cela n'aurait d'importance que si le plus haut dirigeant de la société l'achetait. Convaincre votre supérieur hiérarchique de faire ce qui s'impose ne fera probablement que le renvoyer.

La première chose à faire est de changer le libellé. En l'appelant "dette technique", on donne à la direction l’idée que le permettre est un investissement - quand c’est vraiment un virus. (Je suis comme le Dave Ramsey de la dette technique.)

Le fait de le laisser impayé a un coût énorme qui ne peut être ni vu ni facilement quantifié.

Énumérer des problèmes tels que les suivants pour la gestion:

• Les nouvelles estimations des fonctionnalités sont bien plus élevées que nécessaire. Ou tout à fait impossible.
• Un mauvais code engendre plus de mauvais code
• La liste de bogues s'allonge même si les développeurs les corrigent toujours
• Les membres de l'équipe partent (cela même peut montrer qu'il y a un problème, comme expliqué dans cette excellente réponse )

En réalité, ma direction a commencé à faire un effort sérieux pour régler le problème de la dette technique. C’est l’une des raisons pour lesquelles j’aime travailler ici, mais c’est un effort à long terme et il n’est jamais inutile de leur rappeler pourquoi cet effort en vaut la peine.

Une des façons dont je maintiens la pression est que chaque fois qu'on me demande une estimation, et que l'on aurait pu gagner du temps si je n'avais pas à traiter de problèmes spécifiques de dette technique, je l'inclus dans mon estimation . Par exemple, " Ce bogue va me prendre entre 2 et 3 jours, mais si nous avions déjà résolu ces 2 autres bogues" de faible priorité "qui sont dans la file d'attente, cela prendrait probablement moins d'un. " Souvent, la réponse sera d'aller de l'avant et de réparer les autres pendant que vous y êtes.

Je suis également d’accord avec d’autres réponses sur le fait d’envisager d’améliorer une partie de votre travail et de le faire au fur et à mesure si cela ne gênait pas trop. Ma tâche actuelle consiste à ajouter des éléments à du code très mal conçu. Plutôt que d'ajouter au désordre en écrivant mon nouveau code pour qu'il corresponde, je passe un peu de temps à consolider les fonctionnalités communes. L'envoi d'un paquet devient donc un appel de fonction sur une ligne au lieu de répéter constamment 15 lignes de copies et de modifications légèrement modifiées. coller le passe-partout.

Je sais pertinemment que cela va sauver la santé mentale de certains mainteneurs plus tard. Je sais parce que je suis ce responsable aujourd'hui. Cependant, je pense aussi que cela va accélérer ma propre tâche actuelle d’installation et de débogage de cette fonctionnalité.

Une autre technique que j’ai utilisée par le passé et que je devrais faire à nouveau est de conserver une branche DVCS de refactoring dans un arbre de travail séparé pendant ce temps mort lorsque vous compilez, attendez un long test ou avez simplement besoin d’un changement de rythme. un peu quand vous êtes épuisé par un bogue. Tant que vous fusionnez occasionnellement en amont pour ne pas trop diverger, vous pouvez prendre aussi longtemps que vous le souhaitez pour refactoriser les modifications avec très peu d'effort marginal. 15 minutes ici et là par jour peuvent vraiment s’ajouter au fil du temps.

Vous pouvez essayer l'analogie de carte de crédit. Demandez-leur "vous sentez-vous à l'aise de laisser vos relevés de carte de crédit impayés sur une longue période?"

Les gestionnaires comprennent les coûts et les avantages, mais (généralement) pas les termes techniques utilisés par nous, développeurs. Le terme "dette technique" a déjà été inventé pour aider à surmonter cet obstacle à la communication, mais vous devrez peut-être l'articuler plus clairement. La plupart des gestionnaires savent très bien (souvent par expérience) que les paiements en retard par carte de crédit augmentent avec un taux d'intérêt horrible, il est donc difficile de les laisser impayés. Cela peut les aider à comprendre le problème de l’entropie des logiciels.

Mais si cela ne les convainc pas, essayez de rassembler des preuves factuelles et effectuez des calculs. Par exemple, combien cela coûte-t-il à l'entreprise - à la fois en espèces et en temps perdu - de remplacer un employé qui quitte son emploi

Personne ne donnera de l'argent pour remplacer quelque chose qui fonctionne avec quelque chose d'autre qui fonctionne (avec un peu de chance).

Ce que vous pouvez faire, c'est proposer de le remplacer par quelque chose qui en fasse plus, c'est-à-dire regrouper le service de la dette technologique dans une mise à niveau qui apporte des avantages commerciaux immédiats et tangibles.

Bien sûr, vous devriez être ouvert à ce sujet, nous ne parlons pas de "faufiler" un nouveau projet ici.

Je trouve l’autre côté, celui des développeurs, plus difficile à gérer. En gros, cela revient à ceci: pour certains développeurs, s’assurer que votre code est le meilleur code possible, c’est une question de fierté professionnelle. Pour d'autres, il ne s'agit que d'un autre travail et le but est de le faire rapidement et de rentrer chez soi.

Rien de convaincant ne changera cette situation, et si vous introduisez une norme de qualité du code obligatoire, vos neuf à cinq développeurs trouveront un moyen de faire fonctionner le système, tandis que vos développeurs dédiés seront inévitablement agacés par la procédure complète (qui ne les visez pas, mais vous ne pouvez pas dire que le développeur X doit obéir aux règles, alors que Y peut faire tout ce qu’il veut).

Ce qui fonctionne, mais peut toujours être très frustrant, est d’avoir vos développeurs plus dévoués et mieux informés supervisant le code base, probablement un bon compromis entre aller de l’avant et ranger ce qui est déjà.

Le fait est que, dans de nombreuses entreprises, en particulier compte tenu de la situation économique actuelle, chaque heure doit être facturée à quelqu'un.

Ou ils descendent vite .

À moins que les clients existants ne soient disposés à payer pour la refactorisation, ce qui est profondément improbable si les performances ou les fonctionnalités ne sont pas considérablement améliorées. Ensuite, cela ne se produira pas sur les anciennes bases de code. Vous pourrez peut-être l'insérer dans le budget pour les projets plus récents, si les clients disposent de beaucoup de ressources, mais à moins que vous n'ayez pas besoin de modifier les API dans la refactorisation, cela ne sera d'aucune utilité pour les projets plus anciens et risque fort d'introduire une situation où l’entreprise prend en charge deux bases de code, ce qui occasionne des maux de tête et des coûts supplémentaires.

En tant qu’ingénieur, j’aimerais bien refactoriser l’ancien code, qui n’est plus vraiment adapté à chaque utilisation, chaque fois que quelque chose devient obsolète ou obsolète. Mais comme mes médecins dans toutes les entreprises dans lesquelles j'ai travaillé, m'ont dit: "Qui va payer?"

J'essaie toujours de nettoyer en cours de route. Je n'ai pas fini tant que le code n'est pas propre. Le problème avec la dette technique est que la plupart des gens ne le comprennent pas. La meilleure façon de s’y attaquer est de ne pas en accumuler. Si vos responsables font confiance à vos développeurs pour décider comment résoudre un problème, vous pouvez intégrer l'hygiène du code à toutes les tâches de programmation. Si vous n'archivez jamais de mauvais code, vous n'accumulerez pas de dette. Si vous suivez également la règle du scoutisme (laissez toujours le code plus propre que vous ne l'avez trouvé), votre dette existante disparaîtra lentement.

Je ne vois pas le refactoring comme une tâche distincte de la mise en œuvre de fonctionnalités. C'est une partie intégrante de celui-ci.

Si vous avez affaire à des gestionnaires non techniques, il serait utile de pouvoir exprimer votre discussion en des termes qu’ils comprennent. Si vous pouvez construire un scénario réaliste pour un retour sur investissement positif sur le travail consacré au remboursement de la dette technique, vous obtiendrez peut-être quelque chose. Cet exercice dépendra de votre situation, mais voici un exemple:

Analysez le temps que les développeurs sont obligés de passer à l'assistance du support technique en cas de problèmes de production, puis expliquez que la réparation d'un ancien code trop cruel pourrait A. réduire le nombre de problèmes de support, B. aider le support à résoudre les problèmes sans passer au niveau de développement, et C. Réduisez le temps passé par le développement sur les problèmes de production. En termes d'économies d'argent, les développeurs ne sont pas obligés de faire du travail de support. Signalez également que chaque développeur passe chaque heure à faire du support technique est un "double coup dur", car non seulement vous payez un développeur pour le faire, mais vous réduisez également le coût d'opportunité de ce que ce développeur pourrait faire (ajouter de nouvelles fonctionnalités, etc.). .)

Ouais, certains des chiffres seront voodoo / smoke-and-mirrors ... ça va, le sale secret de la direction est qu'ils savent que la majorité des chiffres sur lesquels ils se frottent sont totaux. BS Tant que vous leur donnez quelque chose apparemment concret de travailler avec, afin qu'ils puissent le prendre dans la tête, vous avez une chance de se battre.

Après cette explication de la dette technique, votre direction doit être convaincue de la payer:

Imaginez que vous avez une cuisine très sale pleine de merde. Avant de préparer un repas, vous devez d'abord passer une heure à nettoyer. Et c'est comme ça chaque fois que tu veux manger. En outre, lors de la préparation d'un repas, vous devez faire très attention à ce que la merde ne tombe pas dans votre repas.

La cuisine est votre code, le repas est votre produit et manger, c'est vendre votre produit.

S'ils peuvent se permettre d'attendre plus longtemps avant qu'un changement soit mis en œuvre, sans un filet de sécurité de tests unitaires, il y a quelque chose qui ne va pas dans votre entreprise.

En ce qui concerne le produit original et l'analyse de rentabilisation, l'argument selon lequel je ne pourrais plus utiliser cet argent pour faire quelque chose de plus important pour moi doit être un argument très convaincant. Qu'on le veuille ou non, votre direction ou vos clients paient pour cela et vous devez être capable de vendre pour les convaincre.

Reformulons ceci pour vous positionner en tant que client. Bon vieux jeu de rôle.

Supposons que vous achetiez un réfrigérateur. Et vous pouvez acheter un réfrigérateur de 1 000 $ qui fonctionne correctement chez Acme Corp. ou un réfrigérateur de 2 000 $ pour Acme Deluxe Des réfrigérateurs qui ont le même aspect extérieur et qui ont les mêmes spécifications techniques, mais dont les coûts de maintenance sont moins élevés en raison d’une architecture interne plus propre.

En tant que client, lequel achèteriez-vous vous-même?

Et quelle est, selon les ingénieurs d'Acme Deluxe, la meilleure solution?

La " dette technique " peut être un sujet délicat à présenter à la direction car elle peut ne pas en voir le besoin. La question pourrait être formulée de manière à savoir s’il existe ou non un champion dans l’entreprise qui doit déclarer: «Regardez, nous prenons X% de temps pour travailler sur la dette technique ici. Donnez-nous trois mois pour vous montrer que cela fonctionne bien» ou quelque chose du genre. similaire. Il y a là une prétention à l'autonomie, mais aussi un laps de temps, sinon la direction peut se demander combien de temps avant de voir des résultats, ce qui est un territoire plutôt dangereux.

Le premier point est cependant de savoir si cela leur pose problème ou non. Si la personne malvoyante ne sait rien des lunettes et quels types de modifications elle peut apporter, comment peuvent-elles comprendre pourquoi un test de la vue pourrait être utile? Même idée ici où le sujet est plutôt technique et malheureusement difficilement quantifiable.

Tu devrais juste arrêter de te plaindre.

Voici pourquoi:

1. Ils ne prévoient jamais d'utiliser le logiciel plus d'un an
2. il est juste une perte de temps le peaufinant si leur plan est de le vider ensuite
3. il y a de vrais problèmes qui doivent être résolus maintenant
4. les programmeurs doivent juste apprendre à gérer l'entretien, même si ce n'est pas toujours amusant
5. se plaindre que vous savez mieux ce qui doit être fait est arrogant - quelqu'un d'autre prend la décision, et vous devriez en être heureux
6. De toute façon, ils vous font confiance pour écrire du bon code

La meilleure façon d'avancer est donc:

1. Quand ils vous donnent une nouvelle tâche, essayez de la mettre en œuvre le mieux possible dans le temps imparti.
2. Écris-le parfaitement la première fois. Si vous devez le changer par la suite, vous commettez une erreur la première fois et tout changement va toujours dans la mauvaise direction - et c'est une opportunité d'apprentissage pour les programmeurs lorsque vous commettez des erreurs.
3. Ne demandez pas de temps supplémentaire pour cela, vous ne l'obtiendrez pas, il y a des délais que vous connaissez.

Je suppose que vous n’avez jamais participé à un projet visant à réécrire / remplacer ou même à mettre à niveau un système existant.

Ce sont quelques-uns des projets les plus difficiles à mener à bien. Certains des problèmes que vous rencontrerez sont:

1. Les règles métier sont perdues dans le temps.
2. La documentation et la mise en œuvre sont totalement désynchronisées.
3. Ce que vous voyez comme un bug que les utilisateurs voient comme une fonctionnalité.
4. Inversement, de nombreuses "fonctionnalités" seront considérées comme des défauts par les utilisateurs.
5. Vous n'obtiendrez pas l'adhésion de l'utilisateur. Ils considéreront votre "recherche de faits" comme des "nerds posant des questions stupides", ils considéreront les tests comme une perte de temps, ils insisteront pour ajouter de nouvelles fonctionnalités, ce qui allongera la durée du projet. déjà être en retard.
6. Les chances sont que le code source ne correspond pas à 100% avec l'exécutable en cours d'exécution.
7. Bien que votre ministère se préoccupe du développement de la refactorisation, l’entreprise souhaite réellement ne pas se faire.
8. Il est probable que votre re-factorisation impliquera des "interfaces améliorées plus propres", entraînant ainsi d'autres projets dans votre fouillis de retard de livraison et de tests infructueux.
9. Une fois le projet mis en attente (plus de 50% de ces efforts échouent complètement), vous perdrez toute crédibilité. Vous devrez changer d’entreprise dans une autre ville pour trouver une personne prête à vous écouter.
10. Si le projet "réussit", tout le monde se souviendra de quel cauchemar c'était - vous allez .......

Je vous exhorte à éviter tout projet de réécriture / refactorisation tel que la peste, car il peut s’agir des expériences les plus décourageantes de toute carrière professionnelle.

Il y a beaucoup de sagesse dans la phrase "Si ce n'est pas cassé ne le répare pas".

Pour ma vie, je ne comprends pas pourquoi certaines personnes ont une peur aveugle du changement - ça sent le manque de confiance en leurs propres capacités.

La nuit dernière, j'ai regardé une émission sur le parc national de Yosemite et il a été remarqué que de 1940 à la fin des années 1990, pas un seul nouvel arbre Sequoia n'a germé. Il a été découvert que la raison en était qu’il existait une politique stricte contre les incendies de forêt et que les cônes de pin séquoia avaient besoin de la chaleur du feu pour s’ouvrir et libérer leurs semences.

Vous voyez, un feu tous les dix ans environ était en bonne santé. Il a effacé tout le bois mort et la ronce accumulés pour maintenir en bonne santé les arbres existants (processus) et faire de la place pour de nouveaux (éléments).

Je suis actuellement sur un projet qui présente des arguments clairs pour la reconstruction: le logiciel hérité a été entièrement écrit à l'aide de formulaires Web .NET. La quasi-totalité de la logique métier est mêlée à la logique d'affichage des balises HTML / serveur et ne peut pas être étendue à d'autres applications maintenant que l'entreprise est en pleine croissance.

La direction est en retard sur la tâche car ils ont une confiance suffisante en leurs développeurs, ce qui, je le réalise, est un luxe rare.

Oui, demandez-vous si une reconstruction est vraiment nécessaire. Faites de votre mieux pour réutiliser le code existant qui fonctionne là où vous le pouvez. Intégrez ce code à la reconstruction si nécessaire. Ne laissez personne vous convaincre qu'avoir peur de faire des changements audacieux est le seul moyen d'exister en tant que développeur de logiciels.

Bonne chance!

Vous devez donner à votre direction une raison financière pour traiter la dette technique et un cadre pour gérer la réduction de cette dette technique.

Maintenir une feuille de route technologique est un tel cadre. Commencer avec une feuille de route vous aidera à vous empêcher de vous accumuler sur la dette technique et peut également vous aider à réduire votre dette existante.

De nombreux projets à long terme couronnés de succès associent des comités directeurs et des feuilles de route pour guider le développement. Celles-ci sont particulièrement utiles lorsque plusieurs équipes de développement et parties prenantes sont impliquées.

Je suggère que vous discutiez de cette stratégie avec vos responsables (et si possible ceux qui décident où l'argent sera dépensé).

L’approche générale pour créer et gérer une feuille de route est simple, mais elle nécessite l’appui de votre équipe de direction. Tout d'abord, définissez un objectif. Définissez les éléments de la dette technique et développez une architecture de système cible réduisant les éléments de votre dette technique. Rappelez-vous qu’il n’est pas nécessaire que ce soit parfait, mais simplement réalisable et meilleur que ce que vous êtes actuellement. Tenez compte des logiciels, des outils de développement, des plates-formes matérielles et des nouvelles fonctionnalités majeures pouvant être ajoutées au système. Faites une analyse des coûts. Si vous avez l'architecture souhaitée, quels sont les avantages concrets de la refactorisation? (Les avantages incluent une durée de test réduite, des produits logiciels plus fiables, des cycles de développement plus prévisibles, etc.) Si vous pouvez montrer suffisamment d'avantages pour effectuer une refactorisation, vous pouvez obtenir un support de gestion.

Une fois que vous avez une feuille de route et un support de gestion, développez une série d'étapes (également appelées un plan) que vous devez suivre pour atteindre cet état souhaité. Il peut être judicieux de mettre en place un comité de pilotage chargé de maintenir la feuille de route, de former et d’éduquer les équipes de développement sur la feuille de route et d’examiner périodiquement les modifications apportées pour assurer l’intégrité de l’architecture.

Les feuilles de route sont vraiment utiles, et peut-être que la 13ème question du test de Joel devrait être "Avez-vous une feuille de route?"

Voici une vidéo de la première heure d'une session récente de feuille de route Red Hat Linux .

Ayant déjà participé à une réécriture majeure (et pas seulement à la refactorisation), je peux convenir que l’obtention du consentement des responsables financiers pour le projet a été l’un des principaux obstacles. Pour surmonter cet obstacle, il a fallu que je rédige, présente et défendais un rapport soulignant un certain nombre de problèmes qui impliquaient que les activités de la société allaient se perdre dans l’eau à court et à moyen terme.

Facteurs clés pour obtenir l'accord d'aller de l'avant:

• Le code existant faisait partie d'une chaîne d'outils (MicroPower Pascal) qui n'était plus prise en charge et qui s'exécutait uniquement sur une plate-forme de développement presque non supportée (PDP11-23).
• Trouver des développeurs capables de travailler sur des outils et des cibles devenait presque impossible.
• Le matériel cible n'était plus disponible si des pièces de rechange étaient nécessaires et le fabricant était de plus en plus réticent à fournir un service de réparation.
• Des problèmes dans le code entraînaient une insatisfaction facilement identifiable des clients et des coûts de maintenance directs.
• L'ajout de nouvelles fonctionnalités ou même de corrections de bugs devenait presque impossible en raison des limitations du matériel cible, d'où la nécessité de refactoriser d'autres zones afin de laisser de la place pour les problèmes.
• Avec un temps de construction de 8 heures, développer et tester tout changement était coûteux.

Le rapport détaille les problèmes, avec une estimation des coûts en cours, et propose 3 options:

1. Freeze où nous étions avec peut-être même pas de corrections de bugs dans un proche avenir.
2. Optimisez le code pour l'espace uniquement, sans égard à la facilité de maintenance, en soulignant que quiconque tenterait de maintenir le code optimisé devrait être plus intelligent que celui qui effectuait l'optimisation.
3. Ré-implémenter, avec la testabilité et la maintenabilité comme facteurs déterminants, dans un langage standard (ANSI C), largement enseigné, sur du nouveau matériel COTS économique et de nouvelle génération (PC-104), avec plusieurs fournisseurs disponibles avec un logiciel interne carte d’interface conçue pour lui permettre de fonctionner avec le reste du matériel existant. Ajout d’un ensemble limité de nouvelles fonctionnalités dans le cadre du développement, telles que stockage non volatile, horloge de surveillance pour permettre un redémarrage automatique en cas de panne, certaines unités tombaient en panne plusieurs fois par jour et nécessitaient un appel de service de 40 £ pour être réinitialisées . de meilleurs diagnostics dans le processus.

Après avoir obtenu le feu vert pour la 3ème option, mon contrat de 3 mois s'est transformé en 3 années de travail très dur, développant à la fois le nouveau logiciel et le nouveau matériel, mais avec un très bon résultat.

Dans les cas de dette technique moins extrême, j'ai tendance à adopter ce que j'appelle le refactoring de guérilla:

En cas de problème avec un module spécifique:

1. Rédigez un ensemble de tests qui démontrent le problème et qui risquent également d'échouer sans refactoring
2. Refactor dans le cadre du développement en soulignant que les tests échouent toujours.