Síntesis diagnóstica — apoyada en Brooks, Glass, ACM
El problema que resuelve
Antes de hablar de soluciones, hay que nombrar el paradigma que las hace necesarias. Existe un patrón cognitivo recurrente en equipos técnicos de alta competencia que produce consistentemente el mismo resultado: sistemas que llegan tarde, más grandes de lo necesario, y menos adaptables de lo que el negocio requiere.
El patrón no es negligencia ni falta de rigor — es exactamente lo contrario. Es rigor mal orientado.
Qué es
Son dos sesgos que operan juntos y se refuerzan mutuamente.
La Completeness Fallacy es la creencia de que un sistema que no está completo está mal hecho. Que entregar algo parcial — aunque funcione, aunque resuelva el problema real del momento — es una falla profesional. Que la arquitectura debe estar entera antes de poder ser usada.
El Correctness Bias es la creencia de que existe una forma correcta de hacer las cosas, y que apartarse de ella — aunque el contexto lo justifique — es incorrecto por definición. Que "suficiente" es sinónimo de descuido. Que lo que se construyó antes y tuvo que evolucionar estaba, por ese solo hecho, mal construido.
Juntos producen el Big Architecture Up Front: la decisión de diseñar todo antes de construir nada, tomada en el momento de menor información disponible, con el mayor costo posible de estar equivocado.
Cómo se manifiesta
No como irracionalidad — eso sería fácil de detectar. Se manifiesta como profesionalismo. Como responsabilidad. Como la convicción de que hacer las cosas bien desde el inicio es siempre superior a hacerlas de forma incremental. El problema es que "bien desde el inicio" requiere saber al inicio lo que solo se puede saber después de operar el sistema en el mundo real.
El sesgo de optimismo en ingeniería de software lleva a falsas suposiciones y conclusiones prematuras sobre la eficiencia o corrección de una solución elegida — ocurre cuando las personas sobreestiman sus capacidades, o cuando se sobreestima la probabilidad de un resultado favorable. Aplicado a arquitectura, ese sesgo produce la ilusión de que es posible anticipar correctamente todos los requisitos antes de que el sistema exista. Ant Murphy
El Second System Effect descrito por Frederick Brooks añade otra capa: la tendencia de sistemas pequeños, elegantes y exitosos a ser sucedidos por sistemas sobrediseñados e inflados, debido a expectativas infladas y exceso de confianza. El arquitecto que "tuvo que arreglar" el sistema anterior llega al siguiente con la convicción de que esta vez lo hará perfecto — y diseña en consecuencia. CliffsNotes
Y la Nirvana Fallacy — documentada en literatura de ingeniería de software — completa el cuadro: las soluciones a problemas son rechazadas porque no son perfectas. Cualquier propuesta incremental, cualquier arquitectura suficiente, cualquier entrega parcial que funcione — es descartada no porque no resuelva el problema, sino porque no lo resuelve todo de una vez. Project Smart
Por qué importa nombrarlo
Porque sin nombre, el patrón se defiende solo. Parece responsabilidad técnica. Parece rigor. Y cualquier argumento en su contra suena a improvisación o a recorte de esquinas.