Démontrer le mauvais code au client?

Question

Un client m'a demandé de faire une refonte de son site Web, une application WebForms ASP.NET qui a été développée par un autre consultant. Cela semblait être un travail relativement simple, mais après avoir regardé le code, il est clair que ce n'est pas le cas.

Cette application n'a pas été bien écrite. Du tout. Il est extrêmement vulnérable aux attaques d'injection SQL, la logique métier se propage dans toute l'application, il y a beaucoup de duplication et du code sans issue qui ne fait rien. En plus de cela, il continue de lancer des exceptions qui sont étouffées, le site semble donc fonctionner en douceur.

Mon travail consiste à mettre à jour simplement le HTML et le CSS, mais une grande partie du HTML est générée dans la logique des affaires et serait un cauchemar à régler. Mon estimation sur la refonte est plus longue que le client visait. Ils demandent pourquoi si longtemps.

Comment puis-je expliquer à mon client à quel point ce code est mauvais? Dans leur esprit, l'application fonctionne très bien et la refonte devrait être une seule offre. C'est ma parole contre le consultant précédent. Comment puis-je donner des exemples concrets simples qu'un client non technique comprendra?

Mise à jour

Merci pour toutes les réponses. La démonstration d'attaque par injection SQL est logique et je vais faire le démon dans un environnement de test. Ce n'est qu'une partie de nombreux problèmes de cette application. Je cherchais des moyens d'expliquer pourquoi d'autres pièces (telles que le HTML généré dans la couche de données) devraient être remplacées par de meilleures pratiques pour que la mise à jour HTML et CSS ait lieu. Il y a beaucoup de bonnes suggestions ici que je vais reconstituer lorsque je parlerai avec mon client.