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


158

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 ?


5
"travailler avec les développeurs" "communiquer ceci à la direction" De quoi parlez-vous? Des développeurs ou des gestionnaires? Quel comportement voulez-vous changer?
S.Lott

45
La dette technique est comme une dette financière: il est beaucoup plus facile à long terme de ne pas l’accumuler pour commencer. Payez toutes vos factures techniques une fois par semaine.
Lawrence Dol

7
Mike> Je pense que vous vivez dans un monde beaucoup moins contraignant, car les délais et les budgets limités dominent le monde dans lequel je vis. Si les logiciels ne s'adaptent pas bien aux besoins futurs et nécessitent beaucoup de travail, la direction se soucie souvent davantage d'ignorer et continuez à utiliser des fonctionnalités. Maintenant, beaucoup de compagnons dans lesquels j'ai travaillé ont mis des feuilles de temps en place. Les développeurs doivent donc enregistrer leur travail. Si vous ne perdez pas de temps, la direction voit le potentiel, vous perdez votre temps.
Desolate Planet

4
Je suppose que vous pourriez dire que c'est un problème d'avantages à court terme par rapport aux avantages à long terme. Si une équipe de logiciels nettoie un système de telle sorte que les nouvelles fonctionnalités prennent moins d’une heure à mettre en œuvre au lieu d’un jour, c’est un avantage immédiat. Si la direction vous voit améliorer le code et aller à l'encontre de ce qu'elle veut, vous êtes un peu rebelle à ses yeux. Je ne sais pas vraiment quelle est la meilleure solution, mais cela semble être un problème si courant et je vois ce que cela fait pour les équipes.
Desolate Planet

3
Scott> Pour répondre à la question, c'est l'attitude de la direction que j'aimerais changer. Les développeurs connaissent le code et ont une expérience directe du code à améliorer pour faciliter les choses. Dans un travail précédent, lorsque nous avions publié une nouvelle version d'une application, le nombre de bogues augmentait à un rythme effroyable. J'ai essayé de mettre en place des stratégies de test, mais cela ressemble souvent à une cause perdue.
Desolate Planet

Réponses:


191

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.


30
mon expérience va généralement dans ce sens. La dette technique est nettoyée à mesure que de nouvelles fonctionnalités sont ajoutées. Parfois, les estimations de certaines corrections / fonctionnalités "associées" sont complétées pour inclure le nettoyage de ces éléments.
Ken Henderson

4
+1 Vous partagez exactement mes sentiments ... sauf que vous vous êtes exprimé beaucoup plus diplomatiquement;)
Michael Brown

7
Bonne réponse. Je ne vois pas encore une entreprise qui serait heureuse de signer un projet de «refactoring» qui ne procurerait aucun avantage au client, mais un code plus ordonné. Refactor-as-you-go.
JBRWilkinson

7
"Quand j'ai rencontré mon patron pour en discuter, il a dit que je devrais inclure le refactoring dans tous mes devis." - C’est l’attitude que je prends et la position de nombreux développeurs dans les équipes au sein desquelles j’ai travaillé. Cependant, lorsque ces 9 à 5 développeurs, comme nous les appelons, sont préoccupés par leurs critiques et leurs augmentations de salaire, ils ne vont pas créer plus de travail pour eux-mêmes. Ils vont suivre ce que la direction pense, après tout, c'est qui les paie.
Desolate Planet

8
@ jmort253: il y a un (léger) problème avec cette politique par ailleurs excellente -> il n'est pas possible d'effectuer des modifications importantes (c'est-à-dire, changer la base de données comme indiqué par l'OP). Ceux-ci doivent être explicitement abordés.
Matthieu M.

48

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.


43

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 )

7
+1, bien que je pense que la dernière balle devrait être "Les bons / meilleurs membres de l'équipe partent"
Ken Henderson

12
Peu de dette technique est un investissement parfois. Si vous faites la course avec une autre entreprise et que le lancement se fait en premier lieu sur le marché, il est logique de créer des raccourcis dans le code pour un lancement plus rapide. Personne ne se souciera que vous ayez un code parfait si vous n'avez aucun client payant.
quant_dev

3
@ quant_dev Si vous voyez ceci comme une dichotomie entre "plus rapide" et "code parfait", alors vous penserez bien sûr de cette façon. Il n'y a aucune raison pour que les raccourcis ne soient pas techniquement valables, auquel cas ils ne sont pas considérés comme une dette technique.
Nicole

2
@Renesis "Il n'y a aucune raison pour que les raccourcis ne soient pas techniquement valables" - ce n'est tout simplement pas vrai.
quant_dev

3
Et parfois, ce n'est pas une dette technique, c'est juste un gâchis: sites.google.com/site/unclebobconsultingllc/…
TrueWill

30

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.


20

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


12

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à.


5
+1 Mais ces développeurs 9-5, eh bien, vous voulez la porte tournante pour eux, idéalement avec une certaine forme d'accélérateur.
Orbling

3
@Orbling: +1. S'ils ne s'en soucient pas assez, ils devraient vraiment travailler ailleurs. C'est génial d'avoir des développeurs qui viennent à vous avec "je viens d'avoir cette idée ...".
Rapidement maintenant

3
@Orbling Dans certains domaines de développement, ils peuvent être utiles. Je ne suis pas du tout un fan du "snobisme des développeurs", mais vous devez trouver le créneau de chacun pour qu'il soit utile. Le pire que vous puissiez faire est de supposer que tout le monde est comme vous.
biziclop

Personnellement, je pense que l’industrie est fortement surpeuplée. Là où je suis basé, la plupart des emplois en logiciels obtiennent environ 300 candidats qui postulent ces jours-ci. Avec ce niveau de concurrence, un employeur peut se permettre d'engager des employeurs qui font un effort supplémentaire et qui sont meilleurs que la moyenne.
Orbling le

"Les améliorations apportées à la refactorisation pour offrir des avantages tangibles (points de vente)", me parle régulièrement notre architecte en chef, je dois donc appuyer cette proposition.
Mario T. Lanza

12

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?"


12

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.


5
Je suis tout à fait d'accord: "La dette technique, c'est comme une dette financière - il est beaucoup plus facile à long terme de ne pas l'accumuler pour commencer. Payez toutes vos factures techniques une fois par semaine"
Lawrence Dol

7

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.


6

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.


4

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?


3
J'ai du mal à déterminer votre position à ce sujet. Je pense que votre réponse est "cela dépend de ce que le client veut". Le problème, c’est que tous les clients ne comprennent pas que le réfrigérateur à bas prix va laisser échapper du congélateur, des bruits généreux et faire du bruit et éventuellement cesser de fonctionner au bout de 5 ans, tandis que l’autre fonctionnera sans heurts pendant 20 ans. et ne pas être remplacé jusqu'à ce qu'il soit considéré comme démodé par les propriétaires qui le revendront en échange d'un nouveau modèle. Pourtant, j'aime la question que vous avez posée. C'est provocant. +1
jmort253

Première ligne - "Ce doit être un argument très convaincant [] que je ne pourrais pas utiliser cet argent maintenant pour faire quelque chose de plus important pour moi." J'utilise l'exemple du réfrigérateur, car franchement, je me fiche de ce qui se passe à l'intérieur de mon réfrigérateur. Je veux juste un résultat. (nourriture froide à un prix raisonnable). Pour être franc, peu m'importe si les ingénieurs du réfrigérateur pensent que c'est un meilleur produit en interne. Je pourrais les consulter mais ce n’est vraiment pas leur décision.
jasonk

3

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.


Je suis entièrement d'accord avec cela et le trouve de plus en plus. Récemment, j'ai rassemblé une liste de défauts qui ont été rouverts parce qu'un correctif approprié n'a pas été mis en place ou des défauts de même nature. Espérons que les développeurs ont mis du temps. Parfois, c’est parfois le cas, mais ce type de données est une base utile pour montrer à la direction à quel point un produit malsain a un impact sur son activité.
Desolate Planet

2
Dans mon lieu de travail actuel, les heures supplémentaires sont attribuées pour les mauvaises raisons. Si l'on consacrait plus de temps à maintenir l'application en bonne santé et non aux problèmes de lutte contre les incendies, on économiserait de l'argent en heures supplémentaires et les développeurs seraient plus autonomes plutôt que de s'épuiser et de se fâcher contre la direction.
Desolate Planet

Mais la direction (dans la plupart des cas correctement!) Le voit de cette façon. J'ai un magimix des années 1980 qui fonctionne toujours et vous me dites de le remplacer juste parce que c'est vieux et que la couleur est démodée!
James Anderson

2

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.

3
Je suis plutôt d'accord, sauf qu'il est bien connu que même les logiciels de mauvaise qualité ont tendance à survivre beaucoup plus longtemps que ne le prévoient leurs créateurs. Mais tu as raison, il vaut mieux ne pas se plaindre. Au lieu de cela, si vous envisagez une refactorisation à échelle limitée qui facilitera la compréhension du code, cela vaut la peine d'aller de l'avant et d'apporter les modifications SANS AUTORISATION au cours de votre maintenance / correction de bogues (et de courir le risque de le faire).
Angelo

@Angelo - Ne serait-il pas préférable d'exprimer vos préoccupations plutôt que de laisser l'équipe souffrir en silence? J'ai vu ce que ce problème fait pour le moral de l'équipe et aussi avec le temps et l'argent gaspillés en heures supplémentaires. Je ne le vois pas comme "gémissant" en tant que tel. Vous ne faites que souligner les risques liés au projet et si vos idées peuvent accélérer les délais de livraison et rationaliser les processus, alors pourquoi ne pas au moins essayer d'exprimer vos préoccupations? Si cela fait la sourde oreille, vous saurez au moins où vous en êtes.
Desolate Planet

2
Vous devez vous plaindre à haute voix , sinon c'est de votre faute si le code d'une autre personne casse ("Vous saviez que c'était un gâchis et n'en avez parlé à personne?"). Se lever et aller "Hé patron, cette merde va tôt ou tard frapper les fans" est essentiel pour garder une équipe de développement fonctionnelle.
Alex

1

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".


1
"Je suppose que vous n'avez jamais été impliqué dans un projet de réécriture / remplacement ou même de mise à niveau et du système existant" - Wrong, 7 ans.
Desolate Planet

1
Je suis tout à fait d'accord pour dire qu'une réécriture complète est souvent un désastre. Mais j'ai trois exemples au cours des 8 dernières années de ma carrière. L’une d’entre elles était un long travail qui nous a permis de mieux conserver le produit, mais n’a fourni aucune valeur commerciale; une autre était une courte réécriture qui a été un succès total; le troisième était une décision de ne pas réécrire, ce qui a finalement tué la société. Choisissez votre poison.
Tom Harrison Jr

1

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!


1
comment cela répond-il à la question posée, "Comment communiquez-vous cela à la direction pour l'intéresser au règlement de la dette technique?"
Gnat

1
@gnat: Comment la plupart des "réponses" répondent-elles directement à cette question? Voir, par exemple, les réponses de James Anderson, tp1, ou toute réponse au sommet avec le plus de votes. Mais pour répondre à votre question, j’ai fourni une autre analogie que le PO peut utiliser. Il me semble que vous êtes simplement en désaccord avec mon opinion sur la question. C'est bien, mais il n'y a aucune raison de procéder par la suite.
Matt Cashatt

1
D'après ma lecture, la réponse que vous faites par dessus semble répondre directement à la réponse demandée, en fonction de l'expérience pertinente: "Quand j'ai rencontré mon patron pour discuter de cela ..." Quant à votre avis, je suis plutôt d'accord avec cela, mais je vote en fonction sur la qualité du contenu, pas sur le point de savoir si j'appuie une opinion ou si je ne suis pas d'accord. Stack échange Q & Un modèle de vote est assez pauvre quand (mal) utilisé pour les sondages d'opinion
moucheron

1
Je recommande de le relire, alors. Décrire une conversation avec son patron concernant une méthode de couverture de la dette technique par remplissage d'estimations pour des travaux futurs ne répond pas à la question suivante: "Comment communiquez-vous cela à la direction pour qu'elle s'intéresse au traitement de la dette technique?" Soit. Néanmoins, je n'ai pas voté à la baisse parce que cela a ajouté à la conversation. Donc, tout ce que vous avez réussi à faire est de faire taire une opinion sur la question avec laquelle vous êtes d’accord sans raison valable. Les "programmeurs" devraient être un endroit où nous pouvons avoir une conversation. Tout n'est pas binaire.
Matt Cashatt

1

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 .


1

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.
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.