Gran bola de lodo

La expresión se popularizó a raíz del artículo de Brian Foote y Joseph Yoder titulado de la misma manera y publicado en 1999, en el que se definía:

Una Gran bola de lodo es una selva de código enrevesado, chapucero, caóticamente estructurado, que crece descontroladamente, que se mantiene como unido a base de cuerda y cinta aislante. Este tipo de sistemas presentan signos inconfundibles de crecimiento incontrolado y constantes necesidades de reparación. Elementos lejanos en el sistema comparten información profusamente, incluso hasta el punto de que prácticamente cualquier información importante se trata de manera global o se duplica. La estructura global del sistema puede no haber llegado a estar claramente definida nunca. Si alguna vez lo estuvo, es probable que se haya deteriorado hasta el punto de ser imposible reconocerla. Los programadores con un mínimo respeto por la estructuración huyen de esta clase de cenagales. Sólo a aquéllos a los que la arquitectura les trae sin cuidado y que tal vez se sienten cómodos programando por inercia parches día tras día para los interminables agujeros de estos diques que hacen aguas por todas partes, no les importa trabajar en tales condiciones.

Los sistemas que son grandes bolas de lodo han sido generalmente desarrollados en diferentes etapas por diferentes individuos que trabajaron en sus distintas piezas y partes. La conveniencia y la comodidad juegan un papel importante en su aparición. Es un antipatrón en el que caen habitualmente los sistemas desarrollados por personas sin formación previa en análisis y diseño de sistemas ni programación.

No obstante, Foote y Yoder no condenan radicalmente la programación de grandes bolas de lodo, señalando que la predominancia de este antipatrón se debe a que funciona, al menos en un primer momento. La consecuencia, sin embargo, es la pesadilla de mantenimiento en que se convierte el software.

Los programadores a cargo de proyectos con grandes bolas de lodo deben estudiar su comportamiento para entender su función y usar este conocimiento como punto de partida para elaborar el conjunto formal de requisitos que un sistema nuevo y correctamente estructurado debería tener para reemplazar al existente. Cambios de tecnología (de una filosofía cliente-servidor a una basada en web, de la utilización de ficheros al empleo de una base de datos, etc.) pueden proporcionar un buen motivo para empezar desde cero.