Comment puis-je être payé pour réduire la dette technique?

Je travaille actuellement pour une petite entreprise qui a peu de produits techniquement compliqués. Je suis le seul et unique développeur pour l'un d'eux. Il y a environ un an, j'ai obtenu la version héritée du produit et j'ai commencé à la "prendre en charge".

Le client ne parle que de nouvelles fonctionnalités, de valeur commerciale et d'autres de ce type. Le problème est que, bien que le code soit en C #, il est assez procédural. Il n'y a pas d'abstractions, les classes ne sont utilisées que lorsque Visual Studio en a besoin - Formulaires, par exemple. Les implémentations de ces classes sont vraiment horribles et le code est vraiment difficile à maintenir.

Pendant toutes ces années, je passe mon temps à refactoriser. Dans la dernière version, il y a de jolies abstractions et autres. J'ai dû réimplémenter un certain nombre de composants à partir de zéro et je pense vraiment que l'ajout de nouvelles fonctionnalités ou le changement de comportement à ces composants est BEAUCOUP plus facile qu'à d'autres.

Le problème est que je passe mon temps. J'aime vraiment les résultats, mais je n'aime pas travailler 12 heures par jour. Avez-vous déjà été dans une situation similaire? Que dois-je essayer? J'ai déjà essayé d'en discuter, mais toujours pas de succès.

J'ai juste peur du moment où nous décidons de mettre en œuvre la nouvelle fonctionnalité qui nécessite de nombreuses modifications du code hérité. Cela pourrait choquer le client: pourquoi avez-vous besoin de 8 heures pour changer ces icônes? Le client ne se soucie simplement pas qu'il y ait 500 places dans le code que je dois changer. Et je devrais aussi trouver tous ces 500 places en premier.

Des idées?

Étape 1: arrêtez de faire des heures supplémentaires non rémunérées.

Vous avez déjà formé votre client et manager depuis un an à croire que le rythme de développement actuel est ce à quoi il faut s'attendre. Cela fait partie de la raison pour laquelle ils ne comprennent pas pourquoi une chose "simple" pourrait prendre une journée entière à faire. Vous n'avez pas besoin de les garder en otage et de tenter de nuire au projet. Mais vous devez expliquer que leurs attentes sont trop élevées et vous avez besoin d'un autre développeur ou plus de temps avant la date limite. Assurez-vous de mentionner spécifiquement à votre gestionnaire que vous avez effectué des heures supplémentaires non rémunérées et que vous prévoyez de ne pas en faire autant. Même si vous le réduisez à 9 heures par jour, la différence sera remarquée. Si votre manager vous demande pourquoi vous ne faites pas votre travail, vous pouvez signaler que vous avez tenu à l'avertir que ce serait le cas.

Étape 2: prendre des notes

Ce n'est pas parce que vous n'avez pas le temps de faire le travail que vous ne pouvez pas le rendre plus facile lorsque le travail (espérons-le) est terminé. Gardez une trace des idées que vous avez pour corriger le code et faites-les apparaître lors des réunions afin que les autres soient conscients de vos préoccupations. Finalement, vous atteindrez un patch lent ou les gens commenceront à comprendre que vos préoccupations ont de la valeur. Lorsque ce moment arrivera, vous aurez déjà quelques idées de base sur ce qu'il faut faire au lieu de le voir à sec car vous n'avez pas regardé une section de code depuis un moment.

... le code est vraiment difficile à maintenir.

C'est votre chemin avec la direction. Démontrez que le coût de la «correction» des bogues et de l'ajout de nouvelles fonctionnalités est supérieur à celui de la refactorisation et de la réécriture du code.

Par exemple, si avec le code actuel, une nouvelle fonctionnalité prendrait 2 semaines à ajouter et ensuite un temps considérable à maintenir (par exemple 1 jour par semaine), montrez qu'avec une refactorisation d'une semaine, vous pouvez faire le développement en 1 1/2 semaines mais que vous réduirez l'entretien à 1 jour par mois (ou moins). Ces chiffres montreront que ce que vous faites est rentable à moyen et long terme même s'il y a un coût à court terme.

Bien que l'entreprise n'aimera peut-être pas dépenser de l'argent maintenant, elle verra que les avantages potentiels sont beaucoup plus importants - c'est-à-dire que vous serez plus productif en générant plus de code en moins de temps et que le code sera de meilleure qualité.

Appliquez la règle du boy-scout : laissez le code un peu plus propre (c'est-à-dire avec moins de dettes techniques) chaque fois que vous le touchez.

Prévoyez du temps pour le faire dans toutes les estimations que vous donnez. Ensuite, comme par magie, avec le temps, la dette technique disparaîtra et vous aurez été payé pour cela.

Cette approche est beaucoup plus facile que d'essayer explicitement de gagner du temps (et donc de convaincre les clients / gestionnaires de payer) pour la dette technique. Cela vous donne un sentiment beaucoup plus grand de professionnalisme et un "travail bien fait". Et enfin, vos clients et managers vous en remercieront à long terme, même s'ils ne comprennent pas très bien comment cela s'est passé .....

C'est plus ou moins la triste réalité des programmes de maintenance. Vous êtes coincé avec ce que vous êtes chargé de maintenir et si la personne qui paie les factures ne veut pas payer ce qu'il considère être des changements sans avantages sociaux, alors ces changements ont tendance à ne pas se faire.

Si vous souhaitez justifier le financement de ces modifications, conservez un journal de tous les emplacements que vous devez modifier, même pour la mise à jour la plus simple. Après quelques modifications, discutez de ce journal avec votre responsable. Si vous pouvez le documenter, il y a une chance (bien que très mince) que la personne avec les cordons de la bourse se rende compte qu'il est en fait moins cher à long terme de nettoyer le code maintenant car cela rendra les changements futurs moins chers.

Vos chances de vendre ce produit augmentent avec la durée d'utilisation de ce produit. Les chances augmentent également si une défaillance du produit est susceptible de provoquer un problème de relations publiques pour le client ou de coûter de l'argent au client.

Sauf cela, apprenez ce que vous pouvez et passez à une autre position avec moins d'entretien.

Vous devez montrer à votre direction comment la refactorisation et l'amélioration du produit bénéficieront à l'entreprise.

Le client ne se souciera probablement pas de savoir si le code est beau ou laid tant qu'il fonctionne, et la direction ne sera pas impatiente d'expliquer au client que ce qu'il a déjà payé a été mal conçu et mal mis en œuvre. Dans le même temps, la direction ne sera pas impatiente de consommer le coût du temps de développement qui n'améliore pas le produit d'une manière visible (facturable).

Alors ... vous devez convaincre la direction que les changements que vous proposez aideront l'entreprise:

• Montrez-leur qu'une meilleure architecture vous permettra d'ajouter de nouvelles fonctionnalités plus rapidement.
• Expliquez qu'en continuant le long du chemin actuel, ils vont se peindre dans un coin.
• Donnez des exemples de modifications très coûteuses à effectuer dans le système actuel, mais qui seraient simples et bon marché avec une meilleure conception.
• Gardez une trace du temps passé à maintenir le code hérité par rapport à l'ajout de fonctionnalités vendables. - Aidez-les à expliquer aux clients actuels et futurs que, même si le système existant était plutôt bon, la nouvelle architecture modernisée permettra de nombreuses nouvelles améliorations, une meilleure fiabilité, etc.
• Atténuez le risque associé aux changements que vous proposez. Les gestionnaires sont peu enclins à prendre des risques, et les modifications radicales d'un système existant semblent intrinsèquement risquées.
  • Priorisez la modernisation des différents composants en fonction des coûts et des avantages et assurez-vous que la direction est en accord avec vos priorités.
  • Utilisez les tests unitaires pour vous assurer que les composants modernisés seront compatibles avec le code hérité restant.
• Suivez l'avancement de l'effort de modernisation. Montrez les avantages dès que possible, mais rappelez à toutes les parties qu'il reste du travail à faire.

Vous ne le réalisez peut-être pas, mais Johnny Cash a prédit le mouvement de refactoring et a écrit une chanson sur la meilleure façon de refactoriser une grande base de code existante.

Bien sûr, il a dû l'envelopper dans une métaphore automobile pour que son public puisse s'y identifier.

"Une pièce à la fois" - Johnny Cash

Il semble que vous puissiez facturer au client le temps que le changement "devrait" prendre et que vous en sortirez bien à long terme.

Si vous aimez nettoyer le code (et il semble que vous en fassiez au moins un peu), allez-y et continuez à le faire, mais ne vous épuisez pas. Cela ne fait aucun bien à vous, à votre entreprise ou à vos autres clients.

Assurez-vous que votre direction et toute personne travaillant avec le client savent que le code n'est pas dans la meilleure forme afin qu'ils puissent prendre une décision éclairée - ce n'est pas parce que vous êtes propriétaire de ce code que vous devriez prendre les décisions commerciales à ce sujet, s'ils ne sont pas conscients des problèmes avec le code, ils ne peuvent pas faire leur travail.

Bien que l'application du client ait une dette technique, n'oubliez pas, ils ont probablement été facturés avec une légère remise. Ils n'ont peut-être pas été informés de cela, mais c'est ce qui se produit lorsque vous prenez l'offre la plus basse.

Ils doivent décider s'ils veulent payer le prix fort pour les changements de fonctionnalités ou s'en passer. C'est leur choix. Vous pouvez les laisser prendre la décision ou continuer à travailler gratuitement. Vous pouvez essayer de mentionner le travail de nettoyage que vous avez effectué et offrir une légère remise pour le travail terminé. Encore une fois, c'est leur choix.

La façon dont j'aborderais cela est de commencer par expliquer le concept de dette technique à vos patrons pour vous assurer qu'ils l'obtiennent. Abordez-le d'un point de vue commercial et commercial Chaque fois qu'ils demandent une nouvelle fonctionnalité, la dette technique accumulée dans le produit affecte votre efficacité, et chaque fonctionnalité coûte donc un peu plus en raison de cette dette.

Une fois qu'ils ont compris de quoi vous parlez, essayez de négocier un peu de votre temps pour réduire la dette technique. Dans mon entreprise, nous avons réussi à pétitionner 10% du temps de chaque développeur afin de travailler sur la réduction de la dette technique.

Une fois que vous avez du temps pour travailler sur cela, assurez-vous de l'utiliser réellement (et ne faites pas seulement 10% d'heures supplémentaires pour le faire - respectez vos armes). Créez un catalogue des éléments de dette technique, hiérarchisez-les et commencez à découper. Vous devez manger l'éléphant une bouchée à la fois.

Et n'oubliez pas de prendre en compte de meilleurs outils. Resharper est un excellent outil de refactoring qui se connecte à Visual Studio.