El "punto de exceso de complejidad" se conoce en inglés como:
OH DIOS MÍO QUE ES ESTA MIERDA.
El problema es que esto puede aplicarse a algo que es realmente simple, pero se implementa de una manera tan horrible que tiene la misma reacción.
Así que distinguir algo muy complejo de algo muy horrible puede ser difícil.
SIN EMBARGO: Lo que en realidad tiende a suceder a todo el software es un proceso como este:
Paso 1: Tener una buena especificación, hacer un buen diseño, implementar cosas buenas. Todo el mundo está feliz.
Al final del paso 1: los desarrolladores se felicitan por la maravillosa elegancia de su diseño y se van felices pensando "Tengo un maravilloso legado aquí para que otros agreguen cosas en el futuro, será maravilloso y el mundo será un mejor lugar."
Paso 2: Se realizan algunos cambios, se agregan cosas, se incluyen nuevas funciones. La arquitectura y la estructura del Paso 1 hicieron de este un proceso bastante sencillo. [Pero vaya, el "factor cruft" solo aumentó un poco.]
Al final del paso 2: los desarrolladores se felicitan por la maravillosa elegancia de su diseño, y se van contentos pensando "Gee, soy tan inteligente de haber tenido en cuenta todo eso en el Paso 1. Esto fue tan bien. Tengo un maravilloso legado aquí para que otros agreguen cosas en el futuro, será maravilloso y el mundo será un lugar mejor ".
Paso 3: se realizan más cambios, se agregan más cosas, se agregan más funciones nuevas, se cambian muchas cosas y se escuchan los comentarios de los usuarios.
Al final del paso 3: los desarrolladores se felicitan a sí mismos por la maravillosa elegancia de su diseño y se van bastante felices pensando "Gee, esta arquitectura es bastante buena para permitir tantos cambios que se insertan fácilmente. Pero estoy un poco infeliz sobre X e Y y Z. Ahora podrían limpiarse un poco. ¡Pero! ¡Ah! ¡Soy tan inteligente de haber hecho todos esos ajustes en el Paso 1. Esto fue tan bien. Tengo un maravilloso legado aquí para otros para agregar cosas en el futuro, será maravilloso y el mundo será un lugar mejor ".
Paso 4: al igual que el paso 3. Excepto:
Al final del paso 4: los desarrolladores piensan: "Esto es tan bueno que se está poniendo feo para mantener. Realmente necesita algunos cambios serios. Realmente no me gusta trabajar en esto. Necesita una refactorización. Me pregunto qué hará el jefe dirá cuando le diga que necesita 6 semanas y que no habrá nada para que los usuarios vean al final de esto ... pero tendré otros 5 años de delicioso alcance de modificación futura al hacer esto ... hmmm ... "Es hora de ir al pub a tomar una cerveza".
Paso 5: se deben realizar muchos cambios.
Y DURANTE el paso 5, los desarrolladores se dicen unos a otros: "Este código apesta. ¿Quién escribió esto? Deberían ser fusilados. Es horrible. Tenemos que volver a escribirlo".
El paso 5 es fatal. Aquí es donde el factor cruft se ha vuelto tan malo que el código no puede tener solo algunos cambios más, sino que debe tener algunos GRANDES cambios.
El problema en el Paso 5 es el deseo de tirarlo y comenzar de nuevo. La razón por la que esto es fatal es "El factor Netscape". Ve a google it. Las empresas MUEREN en este punto, porque comenzar de nuevo significa que comienzas con aproximadamente un 50% de suposiciones en lugar de hechos, 150% de entusiasmo en lugar de conocimiento, 200% de arrogancia en lugar de humildad ("¡Esos tipos eran tan estúpidos!"). Y presentas un montón de nuevos errores.
Lo mejor que puedes hacer es refactorizar. Cambia poco a poco. Si la arquitectura se está cansando un poco, arréglala. Añadir, ampliar, mejorar. Gradualmente. En cada paso del camino, prueba, prueba y prueba un poco más. Cambios incrementales como este significan que 10 años después el código actual y el original son como el hacha del abuelo ("tenía 10 cabezas nuevas y 3 manijas nuevas pero sigue siendo el hacha del abuelo"). En otras palabras, no queda mucho en común. Pero te moviste de lo viejo a lo nuevo de forma gradual y cuidadosa. Esto reduce el riesgo, y para los clientes, reduce el factor cabreado.