Comment aborder l'ol '«Ce sera juste une petite application»? Oui en effet?

Question

Ok, je l'ai rencontré à plusieurs reprises, mais voici le pire scénario légèrement exagéré.

Un client dit "Hé, pouvez-vous nous faire ce petit module pour faire cette petite tâche"?
Moi: "Bien sûr pas de problème".

Ainsi, sur la base des budgets et des contraintes, etc., je saute une partie de l'architecture et je plonge dans le droit et je ne fais pas transpirer.

Ensuite, ils demandent un autre module. Et un autre. Et quelques améliorations. Et tout cela se passe très lentement, attention, au fil des années. Et avant de le savoir, vous avez cette application monstre qui est horriblement architeclée.

Que faites-vous lorsque on vous demande de faire quelque chose de petit? Vous ne savez pas si cela continuera de croître ... si le client continue de demander des ajouts (et ils non plus).

Vous ne pouvez pas trop architecter la chose, car c'est juste une petite application après tout, et ils iront ailleurs si vous dites (en ce que je connais toute voix) "Eh bien, juste au cas, architectes cette chose en couches avec le haut -O-la sécurité et la séparation des préoccupations. En fait, allons avec un outil d'injection de dépendance qui fera vraiment de cette chose Blah bla bla ".

Ils diront "ouais bien" et iront à quelqu'un d'autre.

Le budget, le temps et la perception sont aussi importants que d'architer l'application elle-même.

Comment cela doit-il être abordé?

Je suppose que la question se résume vraiment à "Lorsque vous n'avez pas toutes les informations pour le résultat final de ce qui semble être une petite application, comment éviter (ou atténuer) la prise de décisions architecurales et de conception tôt qui seront complètement Insapraire plus tard?