Grande boule de boue

Le terme a été popularisé par Brian Foote et Joseph Yoder dans leur article de 1999 « Big Ball of Mud », avec la définition suivante :

« Une grande boule de boue est une vaste jungle de code mal structuré, programmé en spaghetti, peu soigné et souvent rafistolé. Ces systèmes témoignent clairement des traces d'une expansion incontrôlée, ainsi que de fréquentes réparations opportunes et improvisées. Les informations sont partagées sans distinction parmi les éléments distants du système, souvent jusqu'au point où presque toutes les informations importantes deviennent globales ou dupliquées. La structure du système dans son ensemble n'a peut-être jamais été bien définie. Si elle l'a été, le système a été tellement détérioré qu'il est impossible de la reconnaître. Les programmeurs avec un brin de sensibilité architecturale fuient ces bourbiers. Seuls ceux qui ne sont pas préoccupés par l'architecture, et qui, peut-être, ne sont pas dérangés par l'inertie d'une corvée quotidienne consistant à coller des rustines sur ces digues défaillantes, sont heureux de travailler sur de tels systèmes. »

— Brian Foote et Joseph Yoder, Big Ball of Mud[1]

Des systèmes en « grande boule de boue » ont normalement suivi un long processus de développement, avec des individus différents travaillant sur diverses parties. Souvent, des systèmes développés par des personnes sans formation d'architecture informatique ou de programmation peuvent tomber dans cet antipattern.

Néanmoins, Foote et Yoder ne condamnent pas universellement la programmation en « grande boule de boue », notant que cet antipattern est courant parce que le système qui s'ensuit fonctionne – du moins initialement. Par contre, les logiciels de ce type deviennent extrêmement difficiles à maintenir et à améliorer.

Les développeurs ou mainteneurs ayant pour charge un projet en grande boule de boue sont fortement encouragés à l'étudier et à comprendre ses fonctionnalités afin de créer les spécifications d'un système bien architecturé ayant pour but de le remplacer. Des changements de technologies, par exemple d'un système client-serveur vers une plateforme web ou l'utilisation d'une base de données au lieu de fichiers, peuvent motiver la décision de tout reprendre depuis le début.

• Méthode agile