Voy a decir algo que podría sonar hereje, especialmente ahora que todos pierden la cabeza porque una IA puede escribir un boilerplate de React en 3 segundos: Escribir código siempre ha sido la parte fácil.

Incluso antes de los copilotos, antes de StackOverflow, picar código nunca fue el verdadero abismo.

Claro, los desarrolladores vivimos en una montaña rusa emocional. Un día te sientes un fraude porque no entiendes una librería nueva, y al día siguiente te sientes un Dios porque optimizaste una consulta SQL. Pero seamos honestos: siempre entregamos.

A punta de puteadas café y deuda técnica, el software sale. La implementación es determinista. El compilador no tiene agenda política.

La verdadera dificultad, la que mata empresas y quema millones, no está en el How (cómo lo construimos), sino en el What (qué construimos) y, sobre todo, en el Why (por qué).

La Falacia de la “Dificultad Técnica”

A menudo, cuando un proyecto se atrasa o falla, escuchamos excusas técnicas: “Es que la arquitectura era compleja”, “Es que la integración con el legacy…”.

Mentira.

La mayoría de las veces, la tecnología es el chivo expiatorio de un problema mucho más profundo: La falta de alineamiento organizacional.

Lo difícil no es levantar un clúster de Kubernetes. Lo difícil es poner de acuerdo a Ventas, Marketing, Producto e Ingeniería sobre qué es “Valor” este trimestre.

El Verdadero “Spaghetti Code” es Organizacional

He visto equipos de ingeniería brillantes, capaces de construir catedrales de software escalable y resiliente, desperdiciar seis meses construyendo absolutamente nada de valor.

¿Por qué?

• Porque la empresa cambió de estrategia tres veces en el mes.
• Porque “alguien” tuvo una idea en la ducha y decidió que era prioridad 1 sin validar con usuarios.
• Porque hay cinco stakeholders con visiones contradictorias del mismo producto, y nadie tiene el coraje de decir “No”.

Ese es el verdadero caos. No es el código desorden en el repositorio, es el desorden en la toma de decisiones.

Construyendo lo Incorrecto, Perfectamente

Hay una tragedia silenciosa en nuestra industria: Hacer ingeniería de primer nivel para productos que nadie quiere.

Podemos tener CI/CD automatizado, tests unitarios al 100% de cobertura, microservicios desacoplados y una UX impecable. Pero si la hipótesis de negocio es basura, o si la organización no entiende su propio mercado, todo ese código es basura de alta fidelidad.

La dificultad real radica en la gestión de la incertidumbre del negocio, no en la técnica:

1. Descubrimiento: ¿Tenemos una idea validada o es solo una alucinación colectiva de la directiva?
2. Foco: ¿Somos capaces de matar 99 buenas ideas para ejecutar la única que importa?
3. Coherencia: ¿Lo que Ventas promete es lo que Producto diseña y lo que Ingeniería construye?

El Refactor más Difícil no es de Código

Como Arquitectos o Líderes Técnicos, nos sentimos cómodos “refactorizando” código. Si una clase está sucia, la limpiamos. Si un módulo está acoplado, lo separamos. Es terapia.

Pero el refactor que realmente duele es el Refactor Estratégico.

Intentar alinear a una empresa que dispara para todos lados es infinitamente más complejo que migrar un monolito a microservicios.

• El código obedece a la lógica.
• Las personas obedecen a incentivos, egos, miedos y políticas.

La Batalla por la Claridad

Aquí es donde el rol de Tecnología cambia. Ya no basta con ser los “constructores”. Si nos quedamos callados esperando tickets, somos cómplices del desperdicio.

Nuestra responsabilidad sube de nivel: debemos exigir claridad.

• “¿Por qué estamos haciendo esto?”
• “¿Qué pasa si no lo hacemos?”
• “¿Cómo sabremos si tuvimos éxito?”

Si las respuestas a estas preguntas son vagas (“para vender más”, “para ser innovadores”), no escribas ni una línea de código. Detén la máquina.

Conclusión: La Tecnología es el Medio, no el Fin

No te engañes pensando que el desafío es aprender el último framework de moda. Eso lo aprendes en un fin de semana.

El desafío real, el que te hará un verdadero líder en esta industria, es navegar la ambigüedad organizacional. Es ayudar a tu empresa a decidir qué NO construir.

Porque escribir código es fácil. Saber qué código merece ser escrito es lo que separa a los feature factories de las empresas que realmente innovan.