Efecto del segundo sistema

El efecto del segundo sistema (también conocido como síndrome del segundo sistema ) es la tendencia a que un primer sistema exitoso (a menudo pequeño y relativamente elegante) sea seguido por un segundo sistema que se vuelve excesivamente complejo o inflado . Este efecto se atribuye comúnmente a una mayor confianza tras el primer éxito y a la acumulación de ideas que se pospusieron del primer sistema y luego se añadieron en masa al segundo. ^{[ 1 ] [ 2 ]}

Fred Brooks introdujo la frase en The Mythical Man-Month (1975) al describir la transición de IBM de sistemas operativos relativamente simples para la serie IBM 700/7000 al mucho más ambicioso OS/360 para la familia IBM System/360 (anunciado en 1964). ^{[ 3 ]}

En la formulación de Brooks, el primer sistema de un arquitecto suele ser "austero y limpio" porque el diseñador aún está aprendiendo y es cauteloso con las generalizaciones inciertas. El segundo sistema es "el más peligroso" porque el diseñador tiene más confianza y se ve tentado a incorporar cada mejora, característica opcional y generalización previamente postergada, lo que da como resultado un sucesor más difícil de construir, comprender y evolucionar. ^{[ 4 ]}

El efecto está estrechamente relacionado con la acumulación de características y la sobregeneralización del diseño, donde el segundo sistema intenta anticipar demasiadas necesidades futuras a la vez en lugar de satisfacer los requisitos actuales y validados. ^{[ 5 ]}

Brooks también describió una segunda variante del efecto que no se centra principalmente en añadir funcionalidades: una tendencia a perfeccionar técnicas que se han vuelto obsoletas debido a que los supuestos básicos del sistema han cambiado (por ejemplo, optimizar en torno a un hardware o modelo operativo antiguo después de que el entorno haya cambiado). Citó OS/360 como ejemplo de este tipo de perfeccionamiento mal aplicado. ^{[ 6 ]}

El efecto del segundo sistema se suele analizar en el contexto de reescrituras importantes (una "versión 2" o segunda implementación), pero puede ocurrir en cualquier segundo sistema a gran escala construido después de un éxito inicial.

En *El hombre-mes mítico* , Brooks argumenta por separado que los equipos a menudo deberían esperar construir un sistema piloto (o desechable) para aprender qué es realmente necesario; la cuestión de gestión es si planificar ese sistema desechable con anticipación o lanzarlo erróneamente como el producto final. ^{[ 7 ]} Esta visión se refleja en literatura posterior sobre diseño de sistemas: Butler Lampson recomienda "planificar para desechar uno" y señala que si hay algo genuinamente nuevo en la función de un sistema, es probable que la primera implementación deba rehacerse. ^{[ 8 ]}

Como resultado, algunos equipos programan deliberadamente una segunda implementación para eliminar errores iniciales, generalizaciones erróneas y la estructura exploratoria de la primera iteración. Este enfoque de "reemplazo planificado" a veces se denomina arquitectura de sacrificio : aceptar que partes o la totalidad de la arquitectura actual se reemplazarán una vez que se comprenda mejor el dominio, y diseñar de manera que el reemplazo sea más sencillo cuando llegue el momento. ^{[ 9 ]}

Una mitigación común es el reemplazo incremental (a menudo descrito como el enfoque de "Higuera Estranguladora"), donde se construye nueva funcionalidad alrededor del sistema heredado y se reemplaza gradualmente, reduciendo el riesgo de un segundo sistema único y completo a la vez. ^{[ 10 ] [ 11 ]}

Brooks sugirió que evitar el fallo del segundo sistema requiere una disciplina explícita, que incluye:

• resistiéndose a la "ornamentación funcional" y a la generalización innecesaria,
• hacer visibles los costos de los recursos para las funciones pequeñas (por ejemplo, presupuestar los costos de memoria y rendimiento por capacidad),
• garantizar un liderazgo arquitectónico experimentado (incluidos arquitectos que ya hayan diseñado múltiples sistemas comparables). ^{[ 12 ]}

En la práctica, las estrategias de mitigación suelen incluir la priorización de requisitos validados, la entrega por etapas, una gestión estricta del alcance y procesos de revisión arquitectónica diseñados para cuestionar las características especulativas.

• Antipatrón
• Crecimiento de funcionalidades
• Efecto de plataforma interna
• Efecto Osborne
• Crisis del segundo año
• Filosofía Unix
• Gran bola de barro
• Patrón de higo estrangulador

• Spolsky, Joel (6 de abril de 2000). "Cosas que nunca debes hacer, parte I" . Joel on Software . Recuperado el 15 de octubre de 2021 .
• Turoff, Adam (21 de agosto de 2007). "Notas sobre Haskell" . Recuperado el 15 de octubre de 2021 .
• Gunton, Neil (20 de julio de 2008). "¿Se consideran perjudiciales las reescrituras?" . Recuperado el 15 de octubre de 2021 .
• Fowler, Chad. "La gran reescritura" . Archivado del original el 8 de diciembre de 2016.