K.I.S.S. no significa lo que crees. Y esa confusión está destruyendo tus proyectos.

1. Simple es objetivo. Fácil es subjetivo.

"Simple" en el sentido de Hickey significa una cosa: que algo tiene una sola responsabilidad, sin entrelazarse con otras cosas. Sin nodos atados. El adjetivo viene del latín simplex: una sola trenza.

"Fácil" es completamente distinto. Es relativo a ti. Lo que te resulta fácil depende de lo que ya conoces, lo que tienes cerca, lo que te es familiar. Un neurocirujano encuentra fácil lo que a ti te parece imposible. Eso no dice nada sobre la simplicidad del procedimiento.

"Simple is an objective property. Easy is a subjective, relative term." Rich Hickey, Simple Made Easy (2011)

El problema práctico: elegimos cosas fáciles pensando que son simples. El resultado es una acumulación silenciosa de complejidad que nadie puso ahí intencionalmente.

2. Tu proyecto no murió por el problema. Murió por tu solución.

Fred Brooks lo llamó en 1986 "complejidad accidental". No es la complejidad que viene del problema en sí, sino la que introducen las soluciones que elegimos. Es la deuda que nadie cobra pero todos pagan.

Hay tres formas en que ocurre: añades una herramienta porque es popular, no porque resuelve algo. Eliges un patrón porque ya lo conoces, aunque sea la respuesta incorrecta para este problema. Combinas demasiadas responsabilidades en un solo componente porque "es más cómodo".

En gestión de proyectos se ve así: procesos que empezaron siendo útiles y se convirtieron en rituales que nadie cuestiona. En prompt engineering: un megaprompt con instrucciones contradictorias que el modelo interpreta de maneras que no predeciste. La complejidad accidental es insidiosa porque siempre tiene una justificación razonable en el momento en que se añade.

3. WhatsApp sostuvo 450 millones de usuarios con 2 ingenieros de backend.

No es un error tipográfico.

WhatsApp fue construida sobre Erlang, un lenguaje creado por Ericsson en los años 80 para redes de telecomunicaciones. La premisa de diseño era simple en el sentido de Hickey: procesos aislados que no comparten estado. Si un proceso falla, falla solo. No arrastra nada.

Discord usa Elixir, el sucesor moderno de Erlang sobre la misma máquina virtual. Misma filosofía. Millones de usuarios simultáneos. Estos sistemas llegaron a la misma conclusión que Hickey desde el mundo de la ingeniería de telecomunicaciones, décadas antes de que nadie lo formulara como principio de diseño.

El estado compartido complica los sistemas. El aislamiento los simplifica. Los números confirman la hipótesis.

4. Tu prompt de 3 líneas no es simple. Probablemente es incompleto.

Hay una confusión recurrente en el mundo de la IA: pensar que un prompt corto es un prompt simple. No necesariamente.

Un prompt simple tiene una sola responsabilidad bien definida: produce un output específico a partir de un input específico. Puede tener muchas líneas si las necesita. Lo contrario de simple no es "largo", es enredado: cuando el prompt mezcla instrucciones de formato con instrucciones de razonamiento, restricciones de tono y reglas de negocio. Cuando un cambio en una parte afecta de formas impredecibles a otra.

Los sistemas de prompts que funcionan en producción tienen la misma arquitectura que el código bien escrito: unidades pequeñas con responsabilidades claras, que se componen. La composabilidad no es solo una virtud del código. Es el principio que hace que los sistemas de IA sean mantenibles.

5. La mejor herramienta de diseño es alejarte del teclado.

En 2010 Hickey dio otra charla: "Hammock-Driven Development." La hamaca es literal. Su argumento: el cerebro procesa problemas de manera diferente cuando no estás mirando una pantalla. La mayoría de los buenos diseños ocurren lejos del teclado.

La implicación para gestión de proyectos es incómoda: si vas directamente a la ejecución sin tiempo de procesamiento real del problema, introduces complejidad accidental desde el primer día. Las decisiones de arquitectura que tomas con prisa son las más difíciles de revertir después.

No es procrastinación. Es reconocer que "pensar el problema" y "ejecutar la solución" son actividades distintas que ocurren en modos cognitivos diferentes. La mayoría de los equipos confunde estar ocupados con estar avanzando.

6. K.I.S.S. intuía esto hace 60 años. Sin las palabras exactas.

El principio K.I.S.S. fue documentado por la Marina de los Estados Unidos en 1960. La intuición era correcta: los sistemas que tienen que funcionar bajo presión necesitan ser simples para poder arreglarse. Un jet que solo puede repararse con herramientas básicas es más confiable en campo que uno que requiere equipo especializado.

Lo que K.I.S.S. nunca resolvió fue la definición operacional de "simple". Por eso funciona como recordatorio pero falla como instrumento. Hickey llegó 50 años después con el lenguaje preciso: simple es ausencia de entrelazamiento. No es ausencia de esfuerzo, ni de longitud, ni de profundidad.

El principio siempre fue correcto. Le faltaba la distinción que lo vuelve aplicable.