Software Architect · Módulo 23
Los anti-patrones no sirven para repartir culpas. Te dan el vocabulario para detectar errores sistémicos de pensamiento antes.
Cargo cult · ivory tower · distributed monolith · premature abstraction
Un error arquitectónico suele parecer inteligente en el momento en que se toma — y caro seis meses después.
El cargo cult copia la forma sin el motivo
Ponerse el uniforme de piloto no significa que puedas aterrizar un avión.
El cargo cult architecture aparece cuando un equipo copia decisiones de empresas grandes sin su contexto: microservicios, service mesh, Kafka, Kubernetes, event sourcing, multi-region. El problema no son las herramientas — es la ausencia de un motivo propio para usarlas.
El chequeo profesional es simple: ¿qué propiedad concreta estamos comprando y por qué importa ahora?
La ivory tower desconecta la arquitectura del código
Un proyectista que nunca pisó la obra corre el riesgo de producir un plano hermoso e inviable.
El arquitecto ivory tower produce diagramas y estándares pero no ve los real constraints: legacy, tooling, developer experience, incidents, deadlines, skills del equipo. El resultado es que las decisiones no se adoptan o se adoptan sólo en el papel.
El arquitecto no tiene que escribir cada línea, pero sí tiene que quedarse cerca del delivery: reviews, prototypes, migraciones, incidents y feedback del equipo.
Un anti-patrón sólo se puede corregir después de que el equipo deja de tomarlo como normal.
Ejemplo: frenar una premature abstraction
Una llave maestra que abre todo suele abrir mal una puerta concreta.
El equipo quiere construir un workflow engine genérico para tres approval flows parecidos. El arquitecto propone implementar primero dos flujos de forma explícita, comparar los variability points y recién después extraer la abstraction.
Eso no es renunciar a la arquitectura. Es protección contra una abstracción que llega antes de que se entienda el dominio.
Antiejemplo: resume-driven development
Comprar una herramienta para la vidriera es riesgoso — vos sos el que la va a usar todos los días.
Los ingenieros eligen una tecnología porque queda bien en el CV o está de moda en las conferencias. El skill set del equipo, el hiring market, la maturity, el tooling, las operations y el soporte a largo plazo no entran en la conversación.
El arquitecto tiene que saber separar la curiosidad tecnológica del valor para el sistema.
- ¿Qué decisiones estamos copiando sin tener un motivo propio? - ¿Dónde el diagrama no coincide con el código real? - ¿Dónde apareció una abstracción antes del tercer caso concreto? - ¿Qué tecnologías elegimos por el equipo y cuáles por moda?