Por Martin Alaimo
Tiempos de cambio
Estamos viviendo un momento fascinante. Cada vez más personas de producto, negocio y diseño quieren entender cómo funciona el software por dentro. Lo vemos en la enorme cantidad de estudiantes que se han sumado a nuestro curso de Tech for Product People y en el auge del "vibe coding".
Celebro esta curiosidad. Es fantástica. Pero también nos obliga a parar la moto y responder una pregunta que antes solo importaba a los ingenieros: ¿qué hace que un software esté bien construido?
Developer, Software Engineer, Vibe Coder...
Tu verdadero enemigo: la complejidad
El mayor problema del software no es que no funcione, sino que se vuelve tan complejo que nadie lo entiende. - John Ousterhout
Imagina una casa donde cada vez que quieres cambiar una bombilla, tienes que revisar la instalación eléctrica completa. Donde nadie sabe qué hace cada interruptor. Donde agregar un enchufe nuevo requiere semanas de trabajo. Eso es software mal diseñado.
La complejidad se acumula silenciosamente. Al principio todo parece funcionar. Pero con el tiempo, cada cambio pequeño se vuelve una odisea. Los equipos se ralentizan. Los bugs se multiplican. Y nadie sabe exactamente por qué.
¿Por qué debería importarte si no programas?
Si trabajas en producto, el diseño del software determina qué tan rápido puedes iterar. Un sistema bien diseñado permite experimentar y pivotar. Uno mal diseñado convierte cada feature en un martirio.
Si estás haciendo vibe coding, entender estos principios es la diferencia entre crear algo que puedes mantener y evolucionar, o un castillo de naipes que se derrumba cuando intentas cambiarlo.
Si tomas decisiones de negocio, software complejo significa equipos más grandes, entregas más lentas y más errores en producción.
Entonces:
1- Las buenas decisiones se esconden, las malas se filtran Cuando el software está mal diseñado, los detalles internos "se filtran" hacia afuera. De pronto, para hacer algo simple, necesitas entender cómo funciona todo el sistema.
2- Velocidad hoy vs. velocidad mañana Los equipos que solo buscan resolver el problema de hoy lo más rápido posible. Van rápido al principio y cada vez más lento. Los que invierten en diseño van un poco más lento al inicio pero mantienen su velocidad a largo plazo.
3- Lo que no se nombra bien, no se entiende Cuando un concepto tiene un nombre claro, todo el equipo puede hablar de él. Cuando los nombres son confusos o inconsistentes, cada conversación requiere explicaciones. Esto aplica también a producto: la claridad en cómo nombramos features, módulos y conceptos impacta directamente en cómo se construyen.
Entender diseño de software no significa que vayas a escribir código. Significa que puedes tener conversaciones más productivas con tu equipo técnico.
La complejidad es el enemigo. El buen diseño es tu defensa.
