Lorsque vous parlez de prouver quelque chose, toutes ces méthodes scientifiques entrent en jeu, et une partie de ce que cela signifie est que si vous acceptez des normes objectives pour décider de ce qui est vrai, vous devez accepter la possibilité que, lors d'une enquête, ces faits ennuyeux s'avérer ne pas être de votre côté.
Dans votre cas, je pense qu'il y a 2 choses à prouver.
Premièrement, que la base de code actuelle est "mauvaise". Ce que vous pouvez probablement prouver, c'est que "l'avis professionnel de presque tous les développeurs qui examinent ce code est qu'il est mauvais".
Deuxièmement, la société ferait mieux de réécrire la base de code. C'est un problème car même si le premier point est vrai, le second ne l'est peut-être pas. De plus, vous n'en savez pas assez pour prendre cette décision. C'est le travail de la direction et si vous voulez qu'ils respectent votre jugement professionnel sur le premier point, vous devez respecter le leur sur le second.
Mais ils ne peuvent pas se prononcer sur le deuxième point sans les informations que vous fournissez. Vous devez communiquer ce que vous savez sur la façon dont les problèmes dans le code affecteront l'entreprise et ce que vous savez sur la façon dont une réécriture aurait un impact sur l'entreprise. C'est difficile, car les deux impliquent de prédire un avenir plein d'incertitudes.
Mais vous pouvez essayer d'énoncer le problème en termes commerciaux. Combien de temps supplémentaire est consacré aux changements et régressions? Combien coûterait une réécriture? À quelle vitesse les coûts du système actuel augmenteront-ils au fil du temps s'ils ne sont pas réécrits? Et s'il y a une augmentation de l'utilisation, quelle est la probabilité d'une catastrophe si le code actuel est conservé? Vous ne pouvez pas vraiment savoir tout cela, mais vous pouvez mieux deviner que quiconque. Donnez une plage ou quelque chose pour communiquer avec quelle précision vous pensez pouvoir prédire ces choses.
La plupart des développeurs n'aiment pas maintenir le code moche. C'est pourquoi il peut être regrettable que le code qui est une évidence à réécrire du point de vue du développeur ne vaille pas la peine d'être réécrit du point de vue commercial.
Par exemple, même si la réécriture se révèle rentable, elle pourrait valoir moins que le coût d'opportunité de dépenser l'argent ailleurs dans l'entreprise. Ou la mauvaise base de code peut prendre plus de temps à changer et avoir plus de régressions, mais pas assez pour rentabiliser une réécriture. Ils chercheront peut-être à se faire racheter au cours des prochains mois, et dépenser de l'argent pour une réécriture apparaîtra dans les livres, mais pas les logiciels de buggy.
Essayez d'y penser du point de vue des entreprises et ne préparez pas les chiffres pour obtenir ce que vous voulez. Une grosse réécriture n'est presque jamais une évidence du point de vue commercial. Si vous voulez prouver quelque chose qui n'est pas directement prouvable, faites de votre mieux pour le réfuter. Si vous continuez à faire de votre mieux pour trouver un moyen de ne pas réécrire à partir de zéro, mais rien de ce que vous proposez n'a de sens, alors il est peut-être temps de réécrire à partir de zéro. Et faire cet effort montrera à votre direction que vous êtes sérieux pour représenter les intérêts de l'entreprise, pas les vôtres (vous représentez les intérêts de l'entreprise, pas les vôtres, non?).